Template Programming

TEMENOS T24 Template Programming

User Guide

Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV. Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Template Programming

Table of Contents Introduction.............................................................................................................................................. 4 Application Overview ........................................................................................................................... 4 Application Environment ...................................................................................................................... 4 Terminology...................................................................................................................................... 4 The Structure.................................................................................................................................... 5 Screen Management ........................................................................................................................ 5 Data Entry Functions........................................................................................................................ 5 Security Management ...................................................................................................................... 6 Validation.......................................................................................................................................... 6 Main File Maintenance ..................................................................................................................... 6 History Maintenance......................................................................................................................... 6 Transaction Journaling and System Recovery ................................................................................ 7 Multi Level Processing ..................................................................................................................... 7 Multi Company Processing .............................................................................................................. 7 Audit Trail ......................................................................................................................................... 7 Close of Business Processing.......................................................................................................... 8 Writing an Application Program ........................................................................................................... 8 Defining the File ............................................................................................................................... 8 Create the file ................................................................................................................................... 9 Application Template...................................................................................................................... 10 Template Type ............................................................................................................................... 10 Description ..................................................................................................................................... 11 Modifications .................................................................................................................................. 11 Inserts............................................................................................................................................. 11 Program Flow ................................................................................................................................. 11 Tailoring the Application Program...................................................................................................... 15 Define Parameters ......................................................................................................................... 15 INITIALISE ..................................................................................................................................... 21 CHECK.FUNCTION ....................................................................................................................... 21 CHECK.ID ...................................................................................................................................... 22 CHECK.RECORD .......................................................................................................................... 22 CHECK.FIELDS ............................................................................................................................. 22 CHECK.DELETE............................................................................................................................ 23 CHECK.REVERSAL....................................................................................................................... 23 CROSS.VALIDATION .................................................................................................................... 23 BEFORE.UNAU.WRITE................................................................................................................. 24

TEMENOS T24 User Guide

Page 2 of 40


AFTER.UNAU.WRITE.................................................................................................................... 24 BEFORE.AUTH.WRITE ................................................................................................................. 24 AFTER.AUTH.WRITE .................................................................................................................... 25 Template Programs ........................................................................................................................... 25 TEMPLATE .................................................................................................................................... 25 TEMPLATE.L ................................................................................................................................. 31 TEMPLATE.T ................................................................................................................................. 33 TEMPLATE.W ................................................................................................................................ 35


Page 3 of 40


Introduction

Application Overview The T24 system for data entry is based on a one to one relationship between the data fields on the screen and the data fields in a file. The only way to enter data into T24 is via an APPLICATION PROGRAM which records the data entered and stores it in an associated file, field by field.

There are three types of application program:

Input allows the full functionality of T24: data entry, authorisation, deletion, history restore etc.

Display Only is used to simply view the data on a file maintained by the system rather than the user.

Utility allows data entry and a Verification function which initiates a process. An example of this would be ENQUIRY.REPORT which records the selection criteria for an enquiry and then on Verification builds a report and spools it.

This section describes the underlying systems which support this functionality and details the procedure to follow and develop a T24 application program.

Application Environment Terminology Term

Description

Product

The collective term for all programs and data files that constitute a T24 implementation. For example, Funds Transfer, Foreign Exchange.

Application

An program or subroutine that allows data entry into a T24 file, e.g. CUSTOMER, FOREX etc. A product will consist of many applications.

Subroutine

A routine invoked by an application program or close of business process, i.e. not directly executable by the user.

Structure

The main supporting sub-system for an application. It manages screen input, security (SMS), file updates etc.


Page 4 of 40


Live file

The file which holds authorised data.

Unauthorised file

The file which holds unauthorised data.

History file

The file which contains copies of previously authorised data.

Concat file

A file which is used as an alternate index to a live file.

Figure 1. - Terminology details

The Structure The application management system (the 'Structure') handles all screen display, data input, simple field validation and master file updates. Therefore applications can be written by just defining their specific file layouts, specialised validation and external file maintenance.

This is achieved by inserting field definitions, validation etc. into a coding TEMPLATE which contains the necessary triggers to invoke the core system.

Screen Management One of the most important aspects of the structure is its screen management capability. Once the application has defined the input fields for the transaction, the structure will present a standard screen for input, display, authorisation, history comparison etc. It will also handle field positioning, page manipulation, data formatting, input enrichment etc. which means that whilst the applications may differ dramatically, the user will always be presented with a standard mechanism for entry or data manipulation. However, this does not mean that the user is constrained to one design of entry screen. The structure also allows a 'version' of the screen to be defined without any coding changes necessary at the application end (see the Version System Administration Guide). The data is presented both in ‘classic’ text based screens and in T24 Browser: neither type of display requires modifications to the application program.

Data Entry Functions The structure provides all the necessary transaction processing functions necessary to complete an application.

•

Input a record

•

Modify an existing record

•

Display a record

•

Delete a record

•

Copy a record

•

Authorise a record

•

Reverse an authorised record

•

Compare history records

•

Restore a record from history

•

List all or a selection of records


Page 5 of 40


In the simplest case, to achieve this functionality the programmer would simply have to enter the field definitions. For more complicated processing the programmer inserts the specialised code necessary for authorisation, deletion etc. in the relevant position in the template.

Security Management The structure provides two important aspects of security management:

•

Access restriction

•

Activity logging

System access can be controlled on four levels: system sign-on (including time restrictions), entry to applications and data records, restricting functionality (e.g. allowing display only) and defining the field values with can be entered (e.g. amount < 10,000).

Logging can be specified from simply recording sign on/off times to recording every access the user makes.

The application program requires no special code to achieve this functionality. See the Security Management System Administration Guide for more details.

Validation Input validation can be specified with the field definitions and hence the structure will check the data entered. The validation available is comprehensive, offering simple checks such as numeric/non-numeric input, to complicated date and amount edit checks. Input can also be verified against an existing table as well as being passed to an application specific routine.

To allow maximum flexibility, the structure can pass control back to the application for further validation at any stage. The template also contains sections for further validation on completion of input (crossvalidation), authorisation, deletion etc.

Main File Maintenance The structure in addition to controlling the transaction input also controls the update of the main transaction file. In this way it can maintain both authorised and unauthorised versions of a record and keep a log of the last user to input/change the data (this it stores in the data record itself).

History Maintenance As an extension of the main file update procedure, the structure will optionally maintain a history of all changes made to the application records. The user will then have the ability to 'walk through' the history file examining every change as it occurred and even restore the last record from history in the case of accidental reversal.


Page 6 of 40


Transaction Journaling and System Recovery The recovery system is based on jBASE transaction management. The physical updates to the database files do not take place until the end of the transaction, i.e. after the commit transaction is performed. It is possible to use the JOURNAL file to store information pertaining to all the writes that occur during transactions input. By default this information is not captured and has to be setup by using the SPF application and setting the field INFO.JOURNAL to Y. To roll back logically within a transaction, due to a program bug or operator override, the procedure has to abort the current transaction and return to the start of the transaction (id input or whatever). This is possible because no updates have actually taken place. This is done automatically; special coding is not required for it. Another advantage of this mechanism is any application errors that cause a program to abort and would normally involve a system restore/roll forward, can be ignored in terms of data integrity.

See the Backup, Restore and Recovery System Administration Guide.

Multi Level Processing A unique feature within the structure enables the user to leave the current transaction, invoke a table lookup or similar process, and then return to the original transaction at the exact point of departure. Additionally the data that was being examined in the table can be inserted into the transaction input field. When operating under T24 Browser this mechanism is used extensively allowing the user to run enquiries, view reports, browse help etc. whilst still in data entry mode.

Multi Company Processing The structure incorporates the concept of multi-company processing whereby branches (or any 'legal vehicle') operating on the system can share certain data files (customer files, tables etc.) whilst still controlling their own financial files. The rules to determine which files can be shared are defined by the application programmer when creating the application, the user can determine the company structure i.e. who shares what.

All files accessed by the system are opened by a standard procedure which, using the rules and existing company structure, determines which disk file should be opened. Hence multiple companies can be set up without modifications to the application code.

Audit Trail All main file updates are 'stamped' by the structure with the name of the inputter and authoriser, date-time, terminal number, company code etc. to provide a comprehensive audit trail. If history is maintained then the audit trail will be carried in the history records as well, providing a log of every update performed.


Page 7 of 40


Close of Business Processing A batch system is provided to control all Close of Business processing. It provides the operator with a controlled environment which handles job scheduling/frequency/ dependency, report routing etc.

Applications can define Close of Business processes (routines and/or operating system commands), which are incorporated into a ‘command stream’, executed by the operator. The environments (company processing details etc.) are initialised by the batch control system so that application programs can be written independently of site configuration.

Writing an Application Program This section describes the necessary steps to writing an application program.

Defining the File Determine the name of the file. It must be meaningful; the name of your file will be the same as the name of your application program, hence do not call it FILE001 or SC007. It should give some indication as to its purpose e.g. CUSTOMER, FUNDS.TRANSFER etc. Note: The file name cannot exceed 25 characters, to allow for the addition of the company mnemonic and the $NAU or $HIS suffix.

Enter the details of the file into the application FILE.CONTROL (in T24). NOTE: Currently this program is only available to the Temenos Development group – other programmers must create the records using the jBASE editor (JED).

Field

Details

DESCRIPTION

What the file will be used for.

PRODUCT

The product code to which it belongs. Use EB until a product code is allocated for client specific developments.

SUFFIXES

Dependent on the application type, for standard applications that require authorisation and have a history the field should be multi-valued and contain $NAU & $HIS. For live files, which have no user input, the field should be blank.

FILE TYPE

jBASE file type.

FILE MODULO

jBASE file modulo.

CLASSIFICATION

File classification; INT – Installation CUS – Customer CST – Customer table FIN – Financial FTD – Financial Table Descriptive FTF – Financial Table Financial CCY – Currency


Page 8 of 40


NOS – Nostro SYS.CLEAR.FILES

Y if the file is to be cleared when financial data is cleared.

CUS.CLEAR.FILES

Y if the file is to be cleared when customer data is cleared.

Figure 2. - Field details Select one of the following (the others are for T24 CORE use only).

Classification

Details

INT

Installation - This covers files like COMPANY, USER, LANGUAGE, where only one version of the file will exist regardless of the number of companies

CUS

Customer - for files where the data can be shared between companies. Primarily static information and tables.

FIN

Financial - for files that hold financial level details (amounts, balances etc.) where the data cannot be shared with other companies.

Figure 1. - Classification details

Create the file To create the file run CREATE.FILES at the awaiting application prompt in T24. It will prompt you for:

1.

The company you wish to create the file in (use the current company for installation level files). Use the COMPANY mnemonic as from the correct COMPANY record.

2.

The name of a select list. If you have a number of files to create you may have a select list containing the name of the files, just return if you don’t have a saved select list.

3.

The names of the file(s) you wish to create (the key to FILE.CONTROL).

Entering at the file name prompt will terminate the prompt and create the files. The files will be created in the data directory, the product will determine which sub-directory they will be created in. You can run this process again if, for example, you decide to add the history file later.

The CREATE.FILES process will create all the necessary files – live, unauthorised and history. It is important to note that all three files are prefixed with either F. or FXXX. (Where XXX is the company mnemonic of the company to which the file belongs).

Hence, an INT level file will be created as F.FILENAME, e.g. F.SECTOR, whilst a FIN or CUS level file would be created as FBNK.FILENAME, e.g. FBNK.ACCOUNT.

Once the files are created, you should write the application program.


Page 9 of 40


Application Template Each application is coded as a subroutine that is called by the structure. The logic and processing flow of the application must follow a strict pattern in order to interface to the structure correctly. A template is provided which contains all the necessary calls and requires only the addition of application specific code in the relevant section.

You must never alter the main code in the template. To add your own logic simply add the code in the relevant sections and un-comment the GOSUB statements.

Each application serves one main file and there is a one to one relationship between the fields on the record and the fields on the screen, i.e. the first field on the record will be input by the first field on the screen and so on. If a client wishes to input the fields in a different order, or to not have all the fields displayed together, a VERSION can be written. See the System Administration Guide.

The main file is the live file or authorised file. In addition there can be two other related files:

The unauthorised file This is suffixed with $NAU and holds the record as input or changed before it has been authorised.

The history file This is suffixed by $HIS and contains images of the record prior to each change.

The user inputs/amends data in the unauthorised file. Another user must then view the data and authorise it at which point it is moved from the unauthorised file into the live file. The existing record in the live file is moved to the history file. The structure handles all the reading and writing of these files. The application program need only be concerned with looking after any subsidiary files that may be required.

Template Type There are four templates to choose from depending on the type of application program:

Type

Description

TEMPLATE

Used for all standard input programs to maintain a live, unauthorised and history file. This template is also used for type ‘U’ programs that have a live and unauthorised file but do not have a history file.

TEMPLATE.L

Used for the display of a 'non-inputtable/live’ file

TEMPLATE.T

Used for the display of a 'concat' file

TEMPLATE.W

Used to allow standard input without an unauthorised file and the verify function to execute special procedures

Figure 4 - Template details TEMENOS T24 User Guide

Page 10 of 40


To create an application program, edit the program using the same name as the file you have created (without the F prefix and suffix) and load the appropriate template. Add the application specific code into the following sections:

Description This section should be used to describe the application, its purpose and its relationship with the rest of the system.

Modifications All modifications should be recorded here. Use the format:

Date

Problem identification number Description of modification

Inserts Add all $INSERTs here. The two main inserts I COMMON and I EQUATE should always be included. I COMMON defines variables and arrays that are initialised on entry into T24 and used by the various routines called within it. It also contains system records such as R.DATES and R.USER that are often required by the application program. I EQUATE contains globally used equates. Both inserts are listed in the appendix. Any application specific commons or equates must be coded in a $INSERT program and included here, common blocks especially should NOT be coded directly into the application.

Program Flow The template structure consists of two halves. The top half that controls the program flow, which must not be changed, and the bottom half that contains ‘GOSUB’ sections where you must insert your application specific code. The top half consists of the following:

GOSUB DEFINE.PARAMETERS

This section contains the field definitions of the file.

IF LEN (FUNCTION) GT 1 THEN GOTO V$EXIT END

Several system utility programs call application subroutines solely to assign the parameter tables for their own use. These calls will exit here.


Page 11 of 40


CALL MATRIX.UPDATE

This routine sets up DEFINE.PARAMETERS.

internal

tables

and

variables

from

the

parameters

assigned

in

GOSUB INITIALISE

Any special initialising for the application should be coded in this routine, e.g. file opening.

CALL RECORDID.INPUT

This routine handles the input of the FUNCTION to be performed (input, authorise, list etc.) and the input of the record key. It sets MESSAGE to 'RET' if the application is to be exited or to 'NEW FUNCTION' if the FUNCTION has been initially input or changed.

GOSUB CHECK.FUNCTION

Any special editing of the function should be performed in this routine.

CALL FUNCTION.DISPLAY

Subroutine to handle list displays.

GOSUB CHECK.ID

Any special editing of the record id should be performed in this routine.

CALL RECORD.READ

This subroutine reads the records from the files into one or more of R.NEW, R.NEW.LAST and R.OLD, depending on the function being used:

FUNCTION I or A If an unauthorised record exists it will be assigned to R.NEW and R.NEW.LAST, otherwise the live record will be assigned to R.NEW and R.NEW.LAST, unless it is also not present, in which case the arrays will be initialised to nulls. R.OLD will be assigned with the live record if it exists, otherwise with nulls.

FUNCTION C


Page 12 of 40


If an unauthorised record exists it will be assigned to R.NEW otherwise R.NEW will be assigned from the live record. R.NEW.LAST and R.OLD will be set to nulls.

If FUNCTION requires a record to be present and it is not found MESSAGE will be set to 'REPEAT'.

GOSUB CHECK.RECORD

Special editing of the record should be coded in this routine.

CALL MATRIX.ALTER

This subroutine does further initialising of the internal parameters dependant on the size and structure of the record, which has been read.

GOSUB PROCESS.DISPLAY

If the application is for a live only file (PGM.TYPE 'L') the program will not allow input.

CALL FIELD.MULTI.INPUT

This routine handles all input to fields when the program has been defined as multiple fields per line by means of a VERSION.

CALL FIELD.MULTI.DISPLAY

Used to display fields when multiple fields per lines are specified.

CALL FIELD.INPUT

The routine that processes all field input when no multiple fields per line are defined by VERSION.

CALL FIELD.DISPLAY

Used to display fields when multiple fields per line are not specified.

GOSUB CHECK.FIELDS

Any special editing checks to be done as the fields are input should be coded in this routine. Cross-field validation should not be carried out here. The order of input may vary.


Page 13 of 40


IF T.SEQU NE '' THEN T.SEQU<-1> = A + 1

T.SEQU is used to indicate the next field to be input. Unless CHECK.FIELDS has set this so that a field in error is re-input, it is incremented to the next sequential field here.

IF MESSAGE EQ 'VAL' THEN

This section of code is entered when the user has ended the field input session by entering the function key F5. MESSAGE is set to 'VAL' if the record was being input or changed and required validation; to 'AUT' if the authorise function is being used.

GOSUB CHECK.DELETE

Special checks needed before an input or change is deleted should be coded in this routine.

GOSUB CHECK.REVERSAL

Special checks needed before an authorised record is reversed should be coded in this routine.

GOSUB CROSS.VALIDATION

This routine should contain all the code necessary to completely validate the record before it is written to file.

GOSUB BEFORE.UNAU.WRITE

Special processing and updating which may be required before the records are written to the unauthorised file should be coded in this routine.

CALL UNAUTH.RECORD.WRITE

This system routine writes the input or changed record to the unauthorised ($NAU) file.

GOSUB AFTER.UNAU.WRITE

Special processing and updating which may be required after the records are written to the unauthorised file should be coded in this routine.


Page 14 of 40


GOSUB BEFORE.AUTH.WRITE

Special processing and updating which may be required before the records are written to the live file should be coded in this routine.

GOSUB AUTH.CROSS.VALIDATION

This routine should contain all the code necessary to completely validate the authorisation prior to updating the file(s).

CALL AUTH.RECORD.WRITE

This system routine writes the input or changed record to the live file.

GOSUB AFTER.AUTH.WRITE

Special processing and updating which may be required after the records are written to the live file should be coded in this routine.

Tailoring the Application Program This section outlines how the template can be tailored to an individual application by inserting code in the special routines to call separate subroutines to perform any additional functions that are required.

Please refer to the Programming Standards API Guide for further details on coding conventions.

Define Parameters The parameters defining each field of the record are assigned in this section. There are five tables of which each element defines the respective field of the prime record. There are also five variables to define the parameters for the record id. When defining the arrays you must use the incrementing variable, Z, to reference the element of the array. In this way fields can be added later without having to renumber all the other array assignments.

The variable V is an important common variable used to hold the number of fields in the record and should be set to Z + 9 for input applications, and Z for display only applications (where Z is the last field defined in the 'F' array).

The Define Parameters section of the template should call a subroutine name XX.FIELD.DEFINITIONS. Again, there is a template (named XX.FIELD.DEFINITIONS) that should be used as a basis for such a routine. In addition, if you have access to the T24 Development Environment (Temenos use only), the table builder can be used to build up the parameter definitions (see the Development Environment chapter in the Temenos Developers’ Guide for further details).


Page 15 of 40


F Array This table is used to define the field name associated with each field. It is a dimensioned array. The corresponding variable for the record id is ID.F. This table also specifies whether the field is a single value, multi-valued or sub-valued. The syntax varies in each case. The record id must be single valued. Note: the maximum size of the field name is 18 characters, which includes any multi-value definitions.

1.

Single valued fields Each element of the array is assigned the text string to be used on the screen to label the field. This can be up to 18 alphanumeric characters and must NOT include spaces. The first two characters cannot be 'XX'. E.g. ID.F = 'CHARGE.CODE' F(Z) = 'CHARGE.TYPE'

2.

Multi-valued fields Any field (except the record id) can be multi-valued. They can be individual multi-valued fields; multi-valued in association with a language code, or part of a group of fields whose multivalues are always in association with each other. Individual multi-valued fields are defined by setting their 'F' table element to 'XX.' followed by the field name. E.g.

F(Z) = ‘XX.NARRATIVE’

Language associated multi-values allow several translations of the value of the field to be held on the record, the appropriate multi-value being used according to the language code of the user. These are defined by setting the 'F' table element to 'XX.LL' followed by the field name. E.g.

F(Z) = ‘XX.LL.DESCRIPTION’

3.

Multi Value Associated Fields Associated groups of multi-values are defined by setting the third character of the 'F' table to '<' for the first field of the association, '-' for intermediate fields and '>' for the last associated field.

= 'XXUPPER.LIMIT'

4.

Sub valued fields Any multi-valued field can be sub-valued. These can be defined individually or as associations on sub-values within each multi-value. Single valued fields or record ids cannot


Page 16 of 40


be sub-valued. Sub-values are defined in the same way as multi-values except characters 4 to 6 of the 'F' table elements are used instead of characters 1 to 3.

= 'XXXX>UPPER.LIMIT'

N Array The 'N' table defines the maximum and minimum length of each field and also whether the field is subject to additional editing on input. It is a dimensioned array. The corresponding variable for the record id is ID.N. The element is assigned with three sub-fields separated by a “.”:

1.

Sub-field 1 This parameter defines the maximum length that will be allowed on input for the field or for each multi-value or sub-value if applicable. e.g.

N(Z)=“35”

This field can have a maximum of 35 characters

If the number is prefixed by 0 (e.g. 035) then leading zeroes will not be removed. If it is prefixed by a leading space then spaces will not be trimmed; if it is not prefixed by a leading space, all leading, trailing and multiple spaces removed.

2.

Sub-field 2 This parameter defines the minimum length that will be allowed on input for the field or for each multi-value or sub-value if applicable. Null, space or zero defines that the field is optional.

3.

Sub-field 3 If this parameter is set to 'C' special editing as coded in the CHECK.FIELDS routine will be performed.

Examples:

'10.3'

Between 3 and 10 characters allowed, no special editing will be done.

'006.6.C'

Input must be 6 characters. Leading zeros will not be removed and the field will be subject to processing by the CHECK.FIELDS routine.

‘35..C'

Up to 35 characters of input will be accepted, leading spaces, trailing spaces and duplicated embedded spaces will be removed. For example, the keyed input 'LLOYDS


Page 17 of 40


BANK PLC' will be edited to 'LLOYDS BANK PLC.' Null will be accepted and the input will be subject to FIELD.CHECKS.

T Array The 'T' table defines additional editing to be carried out when data is input in the fields. It is a dimensioned array. The corresponding variable for the record id is ID.T. Each element consists of a dynamic array. The first field identifies the name of the routine to call to perform specific editing for on data input. Fields 3, 4 and 5 are used to define display masks, input restrictions and display justification respectively. The other fields define parameters, which are used in ways specific to the particular validation subroutine and are described later in this section. The use of Fields 1, 3, 4 and 5 are described here:

Field 1 Each routine is named 'IN2suffix'. This field contains 'suffix'. Below is a summary table of the so-called “IN2 routine” that are available in T24. For more complete details refer to the Standard IN2 Routines API Guide.

Type

Routine

Account Number

IN2ACC,IN2.ACCD,IN2ALL,IN2ANT,IN2INT

Alphabetic

IN2AAA,IN2SSS

Alphanumeric

IN2A,IN2AA,IN2S,IN2SS

Any character

IN2ANY

Amount

IN2AMT

Company Code

IN2COM

Currency Code

IN2CCY,IN2.CCYD

Customer Number

IN2CUS

Date

IN2D,IN2.ACCD,IN2.CCYD,IN2.D,IN2YM,IN2.YM,IN2FQU

Frequency

IN2FQU

Mnemonic

IN2MME

Numeric

IN2, IN2R

Program Name

IN2PG,IN2PV

Range

IN2

Rate

IN2R

Security

IN2SEC

Specific Values

IN2

Swift Characters

IN2S,IN2SS,IN2SSS

Version

IN2PV

Figure 5 - Edit checking details


Page 18 of 40


Field 3 Defines input restrictions and can be any of the following values:

Value

Description

null

Input will be accepted in all circumstances (subject to editing and security restrictions etc.).

NOINPUT

Input will never be allowed

NOCHANGE

Input will not be allowed once the record has been authorised

EXTERN

Input will never be allowed and the field will not be copied by the copy function

Figure 6 - Input restriction details Field 4 This field is used to define a mask for input and display editing. The format of the mask is generally as used by the BASIC function FMT. A special mask is used by routines that edit dates (see the section describing these particular IN2 routines).

Field 5 Defines the display justification, Null = Left justified, R = Right justified.

Field 6 Reserved for future use

Field 7 Fields to be deleted when containing default figures after input of this field when more than one field defined

VM = Field marker

Field 8 Can be set to the following values: •

'NOMODIFY' - No changes allowed to association

•

'NODELETE' - No deletion allowed to association

•

'NOEXPAND' - No expansion allowed to association

The value must be specified for the first field in the association.

Field 9 'Hot Field' properties for browser: •

'HOT.FIELD' – Check field validation will be performed on this field

•

'HOT.VALIDATE' – Check field validation will be performed on ALL fields (equiv. to pressing browser 'Validate' button)


Page 19 of 40


CHECKFILE Array This table defines file look-ups to be performed when the fields are input. This will validate the input as having an existing record on the file and will also retrieve the specified field of that record which is then displayed as enrichment next to the entered field.

The table is a dimensioned array and the corresponding variable for the id is ID.CHECKFILE.

A chain of files may be specified where the value of a specified field on the first record is the id of the next record from which a further id or the final enrichment is obtained. There is no limit to the number of stages in such a chain.

The element of the check file table is a dynamic array that is set up as follows:

1.

Field 1

The external name of the file to be read. (Note: the 'F' prefix should be omitted).

2.

Field 2

The number of the field to be returned as an enrichment or to be used as the id for the next file read. This MUST be a file name defined in the corresponding file layout for the check file.

3.

Field 3

This field is used to define 4 optional parameters. These are separated by '.' and should be assigned as follows:

• Subfield 1 'L' The field is language associated and the enrichment returned will be in the language defined for the user. Null =No language association.

• Subfields 2 and 3 Null. These subfields are not used.

• Subfield 4 'D' The id is date associated and the record with the most recent date should be used. The date is in YYYYMMDD format.

'YM' As for 'D' but the date is in YYYYMM format. null =No date used.


Page 20 of 40


4.

Fields 4 to 6

As fields 1 - 3 but for the second file in the chain.

5.

Fields 7 to 9

For the third file in the chain. Etc.

Example : CHECKFILE(Z) = "SWAP.TYPE":FM:SW.TYP.DESCRIPTION:FM:"L"

CONCATFILE Array Concat files are alternative indexes to the main file and are maintained by the structure. This table defines the concat file for each field as required by the application. The table is a dimensioned array and the corresponding variable for the id is ID.CONCATFILE. Each element is a dynamic array and is assigned as follows:

1.

Field 1

'AL' - The index will be in ascending order, left justified. 'AR' - The index will be in ascending order, right justified. ‘NEW’ – This index must be unique.

2.

Field 2

The name of the concat file (without the 'F' Prefix).

Example:

CONCATFILE(Z) = "AR":FM:"SWAP.CUSTOMER.CONCAT"

INITIALISE This section should be used to perform any initialisation that needs to be done once only when the application is first entered.

CHECK.FUNCTION It may be necessary to prohibit certain functions for the particular application or to perform special checks if such functions are attempted. The error message should be the key to an error in the EB.ERROR application, it should not be changed from the one defined in the TEMPLATE routine. This section should be used for any checks that are to be performed once, only when a new function is selected, e.g.


Page 21 of 40


IF INDEX(‘VH’,V$FUNCTION,1) THEN E = ‘EB-FUNT.NOT.ALLOWED.APP’ CALL ERR V$FUNCTION = '' END

CHECK.ID This subsection will be performed immediately after a record id has been entered. Any special editing of the record id should be coded here. The value entered will be in ID.NEW. If an error is found requiring the id to be re-input, V$ERROR should be set to 1 and a message assigned to E and displayed by call ERR, again the error should be the key to an EB.ERROR record. For rules and examples of how define the key to EB.ERROR is defined in T24 Programming Standards, e.g.

IF (LEN(ID.NEW) > 12) OR NOT(NUM(ID.NEW[8,5])) THEN E = "SW-INVALID.CONTRACT.ID" CALL ERR V$ERROR = 1 END

CHECK.RECORD The record has been read from file when this section is performed and any special editing of the record can be done here. The record will be assigned to one or more fields of R.NEW. If a condition is found requiring the id to be re-input V$ERROR should be set to 1 and a message assigned to E and displayed by call ERR (as above)

CHECK.FIELDS This section should contain the coding for any special editing for input fields which is to be done immediately on input and cannot be achieved using the field parameters in the 'N', 'T' and CHECKFILE tables.

The section will be entered whenever a field has been input for which the third sub field of the 'N' array has been set to 'C'.

The value input will be in COMI and AF, AV and AS will be set to index the appropriate field, multi-value and sub-value of R.NEW. The value entered will NOT have been assigned to R.NEW at this stage. The variable DISPLAY will be assigned with the value of COMI as edited by the IN2 routine defined in the 'T' table element. COMI.ENRI will contain enrichment obtained as defined in the CHECKFILE element for the field.


Page 22 of 40


This section should contain a call to the field check subroutine that must contain the code for all the fields requiring special input checks. The particular code to be executed can be selected by interrogating AF, AV and AS. It should be structured thus:

BEGIN CASE CASE AF = fieldname IF COMI[1,1] NE “A” THEN E = “EB-PREFIX.MUST.BE.A” END CASE AF = nextfield

If an error is detected, the error variable E can be assigned to the required message. The call to ERR will display the message alongside the offending field is invoked on return to the application program. Note: This subsection will only be performed if the User has keyed return to the field. It will not be executed if they have skipped the field using the F2 or F3 function keys.

CHECK.DELETE Code needed to perform additional processing / updating when an unauthorised record is deleted should be CALLED from this section. The flag V$ ERROR should be set to 1 if deletion is not to be permitted.

CHECK.REVERSAL Code needed to perform additional processing / updating when an authorised record is reversed should be CALLED from this section. The flag V$ERROR should be set to 1 if reversal is not to be permitted. Note: This section is invoked on function “R”, when the user authorises the reversal using function “A”. Any special processing should be invoked in the BEFORE.AUTH.WRITE section.

CROSS.VALIDATION This section will be performed only when function key F5 has been entered and V$FUNCTION is 'I' or 'C'. It should be split into three sections with calls to subroutines to process field cross validation, overrides and additional processing.

Field Cross Validation This should contain all the code required to fully validate the record being input or changed. R.NEW will contain the record as input or amended during the current transaction, R.NEW.LAST will hold the record as it was before any input or changes were made and R.OLD will contain the record as it currently stands on the live file.

Fields in error can be flagged with a corresponding error message by calling STORE.END.ERROR with AF, AV and AS set to define the offending field and ETEXT to the message, a key to the EB.ERROR application. The section would normally process all the fields of the record so that the user can see all errors in one attempt.


Page 23 of 40


However, some cross-validation will make it futile checking further fields if related fields are in error. The decision on how to handle the cross-validation must depend on the particular application.

YOU MUST ALWAYS repeat editing done in CHECK.FIELDS as the data can be defaulted via Version in which case CHECK.FIELDS will not be performed. YOU MUST NEVER update files in this section.

Overrides Fields that require overrides (do not embed this in the cross-validation) should be analysed in this subroutine. Any override messages should be displayed by calling STORE.OVERRIDE(CURR.NO) and setting TEXT to the message (do not modify the value of CURR.NO), text should be set as a key to a record in the OVERRIDE application. If TEXT is returned as NO, then exit the subroutine immediately. The subroutine should initialise the override fields by calling STORE.END.ERROR with CURR.NO set to zero at the start of the subroutine.

Additional Processing This called subroutine will only be invoked if the record has passed all cross validation checks and overrides. This should be used to invoke other sub-systems e.g. EB.ACCOUNTING etc.

BEFORE.UNAU.WRITE This section should contain coding to perform processing which is to be done before the record is written to the unauthorised file. It will be executed when V$FUNCTION is D, R, C or I and the section CHECK.DELETE, CHECK.REVERSAL or CROSS.VALIDATION as appropriate have been performed successfully.

Typical use of this section would be to make related updates to other files.

AFTER.UNAU.WRITE The purpose of this section is similar to that of BEFORE.UNAU.WRITE except that it will be performed after the write to the unauthorised file. Do not use this section as the transaction will be complete (data written to disk) after the call to UNAUTH.RECORD.WRITE.

BEFORE.AUTH.WRITE This section is used for any special processing required before the live record is written. It is normally used to invoke accounting in authorisation mode and to handle the authorisation of a reversal. To distinguish between the authorisation of Input and the authorisation of a reversal, the record status must be checked, e.g.

BEGIN CASE CASE RECORD.STATUS[1,3] = "INA" CALL XX.AUTHORISATION


Page 24 of 40


CASE RECORD.STATUS[1,3] = "RNA" CALL XX.REVERSAL END CASE

AFTER.AUTH.WRITE As for BEFORE.AUTH.WRITE but performed after the write. Again do not use this section.

Template Programs The template programs listed here are supplied as part of GLOBUS.BP source code. The programs should always be coped from GLOBUS.BP to the local development area and changes made there, i.e. BNK.BP.

TEMPLATE 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042

* Version 9 15/11/00 GLOBUS Release No. 200504 06/04/05 SUBROUTINE TEMPLATE ****************************************************************** * Enter Program Description Here *----------------------------------------------------------------------------* Modification History: * * 24/09/04 - BG_100007114 * Adding a facility for CHECK.RECORD to speicify code that is only run * first time in during browser stateless sessions * *----------------------------------------------------------------------------$INSERT I_COMMON $INSERT I_EQUATE $INSERT I_GTS.COMMON $INSERT I_F.OFS.STATUS.FLAG ************************************************************************* GOSUB DEFINE.PARAMETERS IF LEN(V$FUNCTION) GT 1 THEN GOTO V$EXIT END CALL MATRIX.UPDATE GOSUB INITIALISE

; * Special Initialising

************************************************************************* * Main Program Loop LOOP CALL RECORDID.INPUT UNTIL (MESSAGE EQ 'RET') V$ERROR = '' IF MESSAGE EQ 'NEW FUNCTION' THEN


Page 25 of 40


043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110

GOSUB CHECK.FUNCTION

; * Special Editing of Function

IF V$FUNCTION EQ 'E' OR V$FUNCTION EQ 'L' THEN CALL FUNCTION.DISPLAY V$FUNCTION = '' END END ELSE GOSUB CHECK.ID ; * Special Editing of ID IF V$ERROR THEN GOTO MAIN.REPEAT CALL RECORD.READ IF MESSAGE EQ 'REPEAT' THEN GOTO MAIN.REPEAT END GOSUB CHECK.RECORD

; * Special Editing of Record

CALL MATRIX.ALTER IF V$ERROR THEN GOTO MAIN.REPEAT LOOP GOSUB PROCESS.FIELDS ; * ) For Input GOSUB PROCESS.MESSAGE ; * ) Applications WHILE (MESSAGE EQ 'ERROR') REPEAT END MAIN.REPEAT: REPEAT V$EXIT: RETURN

; * From main program

************************************************************************* * S u b r o u t i n e s * ************************************************************************* PROCESS.FIELDS: * Input or display the record fields. LOOP IF SCREEN.MODE EQ 'MULTI' THEN IF FILE.TYPE EQ 'I' THEN CALL FIELD.MULTI.INPUT END ELSE CALL FIELD.MULTI.DISPLAY END END ELSE IF FILE.TYPE EQ 'I' THEN CALL FIELD.INPUT END ELSE CALL FIELD.DISPLAY END END WHILE NOT(MESSAGE) GOSUB CHECK.FIELDS

; * Special Field Editing

IF T.SEQU NE '' THEN T.SEQU<-1> = A + 1 REPEAT


Page 26 of 40


111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178

RETURN ************************************************************************* PROCESS.MESSAGE: * Processing after exiting from field input (PF5) IF MESSAGE = 'DEFAULT' THEN MESSAGE = 'ERROR' ; * Force the processing back IF V$FUNCTION <> 'D' AND V$FUNCTION <> 'R' THEN GOSUB CROSS.VALIDATION END END IF MESSAGE = 'PREVIEW' THEN MESSAGE = 'ERROR' ; * Force the processing back IF V$FUNCTION <> 'D' AND V$FUNCTION <> 'R' THEN GOSUB CROSS.VALIDATION IF NOT(V$ERROR) THEN REM > GOSUB DELIVERY.PREVIEW ; * Activate print preview END END END IF MESSAGE EQ 'VAL' THEN MESSAGE = '' BEGIN CASE CASE V$FUNCTION EQ 'D' GOSUB CHECK.DELETE CASE V$FUNCTION EQ 'R' GOSUB CHECK.REVERSAL CASE OTHERWISE GOSUB CROSS.VALIDATION IF NOT(V$ERROR) THEN GOSUB OVERRIDES END END CASE IF NOT(V$ERROR) THEN GOSUB BEFORE.UNAU.WRITE END IF NOT(V$ERROR) THEN CALL UNAUTH.RECORD.WRITE IF MESSAGE NE "ERROR" THEN GOSUB AFTER.UNAU.WRITE END END

; * Special Deletion checks ; * Special Reversal checks ; * Special Cross Validation

; * Special Processing before write

; * Special Processing after write

END IF MESSAGE EQ 'AUT' THEN GOSUB AUTH.CROSS.VALIDATION IF NOT(V$ERROR) THEN GOSUB BEFORE.AUTH.WRITE END

; * Special Cross Validation ; * Special Processing before write

IF NOT(V$ERROR) THEN CALL AUTH.RECORD.WRITE IF MESSAGE NE "ERROR" THEN GOSUB AFTER.AUTH.WRITE END END

; * Special Processing after write

END RETURN


Page 27 of 40


179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246

************************************************************************* * Special Tailored Subroutines * ************************************************************************* CHECK.ID: * Validation and changes of the ID entered. V$ERROR = 0 E = ''

Set ERROR to 1 if in error.

IF E THEN V$ERROR = 1 CALL ERR END RETURN ************************************************************************* CHECK.RECORD: * Validation and changes of the Record. * * * * * *


A application runnin in browser will enter CHECK.RECORD multiple times during a transaction lifecycle. Any validation that must only run when the user first opens the contract must be put in the following IF statement IF OFS$STATUS THEN

; * BG_100007114

END RETURN ************************************************************************* CHECK.FIELDS: REM > CALL XX.CHECK.FIELDS IF E THEN T.SEQU = "IFLD" CALL ERR END RETURN ************************************************************************* CROSS.VALIDATION: * V$ERROR = '' ETEXT = '' TEXT = '' * REM > CALL XX.CROSSVAL * * If END.ERROR has been set then a cross validation error has occurred * IF END.ERROR THEN A = 1 LOOP UNTIL T.ETEXT <> "" DO A = A+1 ; REPEAT T.SEQU = "D" T.SEQU<-1> = A V$ERROR = 1 MESSAGE = 'ERROR' END RETURN ; * Back to field input via UNAUTH.RECORD.WRITE


Page 28 of 40


247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314

************************************************************************* OVERRIDES: * * Overrides should reside here. * V$ERROR = '' ETEXT = '' TEXT = '' REM > CALL XX.OVERRIDE * * IF TEXT = "NO" THEN V$ERROR = 1 MESSAGE = "ERROR"

; * Said NO to override ; * Back to field input

END RETURN ************************************************************************* AUTH.CROSS.VALIDATION: RETURN ************************************************************************* CHECK.DELETE: RETURN ************************************************************************* CHECK.REVERSAL: RETURN ************************************************************************* DELIVERY.PREVIEW: RETURN ************************************************************************* BEFORE.UNAU.WRITE: * * Contract processing code should reside here. * REM > CALL XX. ;* Accounting, Schedule processing etc etc IF TEXT = "NO" THEN CALL TRANSACTION.ABORT V$ERROR = 1 MESSAGE = "ERROR" RETURN END

; * Said No to override ; * Cancel current transaction ; * Back to field input

* * Additional updates should be performed here * REM > CALL XX...


Page 29 of 40


315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377

RETURN ************************************************************************* AFTER.UNAU.WRITE: RETURN ************************************************************************* AFTER.AUTH.WRITE: RETURN ************************************************************************* BEFORE.AUTH.WRITE: BEGIN CASE CASE R.NEW(V-8)[1,3] = "INA" REM > CALL XX.AUTHORISATION CASE R.NEW(V-8)[1,3] = "RNA" REM > CALL XX.REVERSAL

; * Record status ; * Record status

END CASE RETURN ************************************************************************* CHECK.FUNCTION: * Validation of function entered.

Set FUNCTION to null if in error.

IF INDEX('V',V$FUNCTION,1) THEN E = 'EB.RTN.FUNT.NOT.ALLOWED.APP' CALL ERR V$FUNCTION = '' END RETURN ************************************************************************* INITIALISE: RETURN ************************************************************************* DEFINE.PARAMETERS: * SEE 'I_RULES' FOR DESCRIPTIONS * REM > CALL XX.FIELD.DEFINITIONS RETURN ************************************************************************* END


Page 30 of 40


TEMPLATE.L 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060

* Version 6 22/05/01

GLOBUS Release No. 200505 22/04/05

SUBROUTINE TEMPLATE.L ********************************************************************* ********************************************************************** * 02/09/02 - GLOBUS_EN_10001055 * Conversion Of all Error Messages to Error Codes ********************************************************************* $INSERT I_COMMON $INSERT I_EQUATE $INSERT I_F.ACCOUNT ;* Other Inserts required for Checkfiles, etc. $INSERT I_F.CUSTOMER $INSERT I_F.SEC.ACC.MASTER ************************************************************************* GOSUB INITIALISE

; * Special Initialising

GOSUB DEFINE.PARAMETERS IF LEN(V$FUNCTION) GT 1 THEN GOTO V$EXIT END CALL MATRIX.UPDATE ************************************************************************* * Main Program Loop LOOP CALL RECORDID.INPUT UNTIL MESSAGE = 'RET' DO V$ERROR = '' IF MESSAGE = 'NEW FUNCTION' THEN GOSUB CHECK.FUNCTION


IF V$FUNCTION EQ 'E' OR V$FUNCTION EQ 'L' THEN CALL FUNCTION.DISPLAY V$FUNCTION = '' END END ELSE GOSUB CHECK.ID ; * Special Editing of ID IF V$ERROR THEN GOTO MAIN.REPEAT CALL RECORD.READ IF MESSAGE = 'REPEAT' THEN GOTO MAIN.REPEAT END


Page 31 of 40


061 062 CALL MATRIX.ALTER 063 064 GOSUB PROCESS.DISPLAY ; * For Display applications 065 066 END 067 068 MAIN.REPEAT: 069 REPEAT 070 071 V$EXIT: 072 RETURN ; * From main program 073 074 ************************************************************************* 075 * S u b r o u t i n e s * 076 ************************************************************************* 077 078 PROCESS.DISPLAY: 079 080 * Display the record fields. 081 082 IF SCREEN.MODE EQ 'MULTI' THEN 083 CALL FIELD.MULTI.DISPLAY 084 END ELSE 085 CALL FIELD.DISPLAY 086 END 087 088 RETURN 089 090 ************************************************************************* 091 * Special Tailored Subroutines * 092 ************************************************************************* 093 094 CHECK.ID: 095 096 * Validation and changes of the ID entered. Set ERROR to 1 if in error. 097 098 099 RETURN 100 101 102 ************************************************************************* 103 104 CHECK.FUNCTION: 105 106 * Validation of function entered. Set FUNCTION to null if in error. 107 108 IF INDEX('V',V$FUNCTION,1) THEN 109 E ='EB.RTN.FUNT.NOT.ALLOWED.APP.17' 110 CALL ERR 111 V$FUNCTION = '' 112 END 113 114 RETURN 115 116 ************************************************************************* 117 118 INITIALISE: 119 * 120 * Define often used checkfile variables 121 * 122 CHK.ACCOUNT = "ACCOUNT":FM:AC.SHORT.TITLE:FM:"L" 123 CHK.CUSTOMER = "CUSTOMER":FM:EB.CUS.SHORT.NAME:FM:'.A' 124 CHK.CUSTOMER.SECURITY = "CUSTOMER.SECURITY":FM:0:FM:'':FM:"CUSTOMER":FM:EB.CUS.SHORT.NAME:FM:'..S' 125 CHK.SAM = "SEC.ACC.MASTER":FM:SC.SAM.ACCOUNT.NAME:FM:'..S' 126 127


Page 32 of 40


128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158

RETURN ************************************************************************* DEFINE.PARAMETERS:* SEE 'I_RULES' FOR DESCRIPTIONS * MAT F = "" ; MAT N = "" ; MAT T = "" MAT CHECKFILE = "" ; MAT CONCATFILE = "" ID.CHECKFILE = "" ; ID.CONCATFILE = "" ID.F = "KEY" ; ID.N = "___" ; ID.T = "_" *

Z=0 * REM > Z+=1 ; F(Z) = "XX.XX.FIELD.NAME" ; N(Z) = "35.2" ; T(Z) = "A" REM > CHECKFILE(Z) = CHK.ACCOUNT * * * Live files DO NOT require V = Z + 9 as there are not audit fields. * But it does require V to be set to the number of fields * V = Z RETURN ************************************************************************* END

TEMPLATE.T 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032

* Version 5 02/06/00

GLOBUS Release No. G15.0.01 31/08/04

SUBROUTINE TEMPLATE.T *MODIFICATIONS ************************************************************************* *18/05/00 - GB0001261 * Jbase changes. * All the commented lines containing the keyword ERROR * has been changed to V$ERROR * * 02/09/02 - GLOBUS_EN_10001055 * Conversion Of all Error Messages to Error Codes * *MODIFICATIONS ***************************************************************** *18/05/00 - GB0001261 * Jbase changes. * All commented lines containing the key word ERROR has been * changed to V$ERROR. $INSERT I_COMMON $INSERT I_EQUATE ************************************************************************* GOSUB DEFINE.PARAMETERS IF LEN(V$FUNCTION) GT 1 THEN GOTO V$EXIT END


Page 33 of 40


033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 100

CALL MATRIX.UPDATE REM > GOSUB INITIALISE

;* Special Initialising

************************************************************************* * Main Program Loop LOOP CALL RECORDID.INPUT UNTIL MESSAGE = 'RET' DO V$ERROR = '' IF MESSAGE = 'NEW FUNCTION' THEN GOSUB CHECK.FUNCTION


IF V$FUNCTION EQ 'E' OR V$FUNCTION EQ 'L' THEN CALL FUNCTION.DISPLAY V$FUNCTION = '' END END ELSE REM > REM >

GOSUB CHECK.ID IF V$ERROR THEN GOTO MAIN.REPEAT

;* Special Editing of ID

CALL RECORD.READ IF MESSAGE = 'REPEAT' THEN GOTO MAIN.REPEAT END CALL MATRIX.ALTER CALL TABLE.DISPLAY

; * For Table Files

END MAIN.REPEAT: REPEAT V$EXIT: RETURN


************************************************************************* * Special Tailored Subroutines * ************************************************************************* CHECK.ID: * Validation and changes of the ID entered.


RETURN ************************************************************************* CHECK.FUNCTION: * Validation of function entered.


IF INDEX('V',V$FUNCTION,1) THEN


Page 34 of 40


101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134

E ='EB.RTN.FUNT.NOT.ALLOWED.APP.17' CALL ERR V$FUNCTION = '' END RETURN ************************************************************************* INITIALISE: RETURN ************************************************************************* DEFINE.PARAMETERS:* SEE 'I_RULES' FOR DESCRIPTIONS * MAT F = "" ; MAT N = "" ; MAT T = "" MAT CHECKFILE = "" ; MAT CONCATFILE = "" ID.CHECKFILE = "" ; ID.CONCATFILE = "" REM > ID.F = "Key.Description"; ID.N = "____"; ID.T = "_" REM > ID.CHECKFILE = "Main.File.Name" : FM : Enrichment.Field REM > F(1) = "XX.LL.Index.Description"; N(1) = "35.3" REM > CHECKFILE(1) = "Indexed.File.Name" : FM : Enrichment.Field RETURN ************************************************************************* END

TEMPLATE.W 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029

* Version 8 02/06/00

GLOBUS Release No. G15.0.01 31/08/04

SUBROUTINE TEMPLATE.W * * MODIFICATIONS * *18/05/00 - GB0001261 * The keyword ERROR in all the commented statements has been * changed to V$ERROR. * * 02/09/02 - GLOBUS_EN_10001055 * Conversion Of all Error Messages to Error Codes ************************************************************************* $INSERT I_COMMON $INSERT I_EQUATE $INSERT I_SCREEN.VARIABLES ************************************************************************* * Call $RUN Routine and Exit if running as Phantom * IF PHNO THEN REM > CALL TEMPLATE.W$RUN GOTO V$EXIT END ************************************************************************* GOSUB DEFINE.PARAMETERS


Page 35 of 40


030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097

IF LEN(V$FUNCTION) GT 1 THEN GOTO V$EXIT END CALL MATRIX.UPDATE REM > GOSUB INITIALISE

;* Special Initialising

************************************************************************* * Main Program Loop LOOP CALL RECORDID.INPUT UNTIL MESSAGE = 'RET' DO V$ERROR = '' IF MESSAGE = 'NEW FUNCTION' THEN GOSUB CHECK.FUNCTION


IF V$FUNCTION EQ 'L' THEN CALL FUNCTION.DISPLAY V$FUNCTION = '' END IF V$FUNCTION EQ 'V' THEN FILE.TYPE = "I" END END ELSE GOSUB CHECK.ID ; * Special Editing of ID IF V$ERROR THEN GOTO MAIN.REPEAT CALL RECORD.READ IF MESSAGE = 'REPEAT' THEN GOTO MAIN.REPEAT END CALL MATRIX.ALTER REM > GOSUB CHECK.RECORD REM > IF V$ERROR THEN GOTO MAIN.REPEAT

;* Special Editing of Record

REM > GOSUB PROCESS.DISPLAY

;* For Display applications

LOOP GOSUB PROCESS.FIELDS ; * ) For Input GOSUB PROCESS.MESSAGE ; * ) Applications WHILE MESSAGE = 'ERROR' DO REPEAT END MAIN.REPEAT: REPEAT V$EXIT: RETURN


************************************************************************* * S u b r o u t i n e s * *************************************************************************


Page 36 of 40


098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165

PROCESS.FIELDS: * Input or display the record fields. LOOP IF SCREEN.MODE EQ 'MULTI' THEN IF FILE.TYPE EQ 'I' THEN CALL FIELD.MULTI.INPUT END ELSE CALL FIELD.MULTI.DISPLAY END END ELSE IF FILE.TYPE EQ 'I' THEN CALL FIELD.INPUT END ELSE CALL FIELD.DISPLAY END END UNTIL MESSAGE <> "" DO REM > GOSUB CHECK.FIELDS

;* Special Field Editing

IF T.SEQU NE '' THEN T.SEQU<-1> = A + 1 REPEAT RETURN ************************************************************************* PROCESS.MESSAGE: * Processing after exiting from field input (PF5) IF MESSAGE = 'VAL' OR MESSAGE EQ 'VER' THEN MESSAGE = '' BEGIN CASE CASE V$FUNCTION EQ 'R' END.ERROR = "" REM > GOSUB CHECK.REVERSAL ;* Special Reversal checks CASE V$FUNCTION EQ 'V' REM > GOSUB CHECK.VERIFY ;* Special Verify checks GOSUB CHECK.CHANGES ; * look for changed field IF YWRITE EQ 0 AND NOT(END.ERROR) THEN GOSUB CALL.$RUN ; * update using $RUN GOTO PROCESS.MESSAGE.EXIT ; * and return to Id input END CASE OTHERWISE REM > GOSUB AUTH.CROSS.VALIDATION ;* Special Cross Validation END CASE IF END.ERROR THEN GOSUB POINT.TO.ERROR GOTO PROCESS.MESSAGE.EXIT END REM > IF NOT(V$ERROR) THEN REM > GOSUB BEFORE.AUTH.WRITE REM > END

; * position on error field ; * return to field input

;* Special Processing before write

IF NOT(V$ERROR) THEN CALL AUTH.RECORD.WRITE IF MESSAGE <> "ERROR" THEN REM > GOSUB AFTER.AUTH.WRITE


;* Special Processing after write

Page 37 of 40


166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233

IF V$FUNCTION EQ 'V' THEN GOSUB CALL.$RUN END END END END PROCESS.MESSAGE.EXIT: RETURN ************************************************************************* PROCESS.DISPLAY: * Display the record fields. IF SCREEN.MODE EQ 'MULTI' THEN CALL FIELD.MULTI.DISPLAY END ELSE CALL FIELD.DISPLAY END RETURN ************************************************************************* CHECK.CHANGES: YWRITE = 0 IF END.ERROR EQ '' THEN A = 1 LOOP UNTIL A GT V OR YWRITE DO IF R.NEW(A) NE R.OLD(A) THEN YWRITE = 1 ELSE A += 1 REPEAT END RETURN ************************************************************************* POINT.TO.ERROR: IF END.ERROR EQ 'Y' THEN P = 0 ; A = 1 LOOP UNTIL T.ETEXT NE '' DO A += 1 REPEAT T.SEQU = A IF SCREEN.MODE EQ 'SINGLE' THEN IF INPUT.BUFFER[1,LEN(C.F)] EQ C.F THEN INPUT.BUFFER = INPUT.BUFFER[LEN(C.F) + 2,99] ; * cancel C.F function after C.W usage ; * (+2 for space separator) END END ELSE E = T.ETEXT CALL ERR END END ELSE T.SEQU = 'ACTION' ; E = END.ERROR ; L = 22 CALL ERR END CALL DISPLAY.MESSAGE("", "1")


; * Clear the VALIDATED message

Page 38 of 40


234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301

VAL.TEXT = "" MESSAGE = 'ERROR' RETURN ************************************************************************* CALL.$RUN: * Process the 'Work' file using the $Run Routine * V$FUNCTION = FUNCTION.SAVE REM > CALL TEMPLATE.W$RUN IF V$FUNCTION EQ 'B' THEN V$FUNCTION = 'V' END RETURN ************************************************************************* * Special Tailored Subroutines * ************************************************************************* CHECK.ID: * Validation and changes of the ID entered.


RETURN ************************************************************************* CHECK.RECORD: * Validation and changes of the Record.


RETURN ************************************************************************* CHECK.FIELDS: RETURN ************************************************************************* AUTH.CROSS.VALIDATION: RETURN ************************************************************************* CHECK.REVERSAL: RETURN ************************************************************************* CHECK.VERIFY: RETURN


Page 39 of 40


302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361

************************************************************************* AFTER.AUTH.WRITE: RETURN ************************************************************************* BEFORE.AUTH.WRITE: RETURN ************************************************************************* CHECK.FUNCTION: * Validation of function entered.


FUNCTION.SAVE = V$FUNCTION IF V$FUNCTION EQ "B" THEN V$FUNCTION = "V" ID.ALL = "" END IF INDEX('ADEFQ',V$FUNCTION,1) THEN E ='EB.RTN.FUNT.NOT.ALLOWED.APP.17' CALL ERR V$FUNCTION = '' END RETURN ************************************************************************* INITIALISE: RETURN ************************************************************************* DEFINE.PARAMETERS:* SEE 'I_RULES' FOR DESCRIPTIONS * MAT F = "" ; MAT N = "" ; MAT T = "" MAT CHECKFILE = "" ; MAT CONCATFILE = "" ID.CHECKFILE = "" ; ID.CONCATFILE = "" REM > ID.F REM > F(1)

= "KEY"; ID.N = "____"; ID.T = "_" = "XX.LL.DESCRIPTION"; N(1) = "35.3"; T(1)

= "A"

REM > V = NumberOfFields + 9 RETURN ************************************************************************* END


Page 40 of 40

Template Programming

Recommend Documents