TEMENOS T24 Template Programming - MarkMail

User Guide

TEMENOS T24

Template Programming

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.


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



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.



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



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 (cross-validation), 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.



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



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



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



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



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.



CALL MATRIX.UPDATE

This routine sets up internal tables and variables from the parameters assigned in DEFINE.PARAMETERS.

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



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.



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.



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



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

= 'XX<CURRENCY'

= 'XX-CHARGE.RATE'

= 'XX-LOWER.LIMIT'

= 'XX>UPPER.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



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.

= 'XX<CURRENCY'

= 'XX-XX<CHARGE.RATE'

= 'XX-XX-LOWER.LIMIT'

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



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



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 VM = Field marker when more than one field defined

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)



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.



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.



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.



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.



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



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 * Version 9 15/11/00 GLOBUS Release No. 200504 06/04/05 002 SUBROUTINE TEMPLATE 003 ****************************************************************** 004 * Enter Program Description Here 005 *----------------------------------------------------------------------------- 006 * Modification History: 007 * 008 * 24/09/04 - BG_100007114 009 * Adding a facility for CHECK.RECORD to speicify code that is only run 010 * first time in during browser stateless sessions 011 * 012 *----------------------------------------------------------------------------- 013 $INSERT I_COMMON 014 $INSERT I_EQUATE 015 $INSERT I_GTS.COMMON 016 $INSERT I_F.OFS.STATUS.FLAG 017 ************************************************************************* 018 019 GOSUB DEFINE.PARAMETERS 020 021 IF LEN(V$FUNCTION) GT 1 THEN 022 GOTO V$EXIT 023 END 024 025 CALL MATRIX.UPDATE 026 027 GOSUB INITIALISE ; * Special Initialising 028 029 ************************************************************************* 030 031 * Main Program Loop 032 033 LOOP 034 035 CALL RECORDID.INPUT 036 037 UNTIL (MESSAGE EQ 'RET') 038 039 V$ERROR = '' 040 041 IF MESSAGE EQ 'NEW FUNCTION' THEN 042



043 GOSUB CHECK.FUNCTION ; * Special Editing of Function 044 045 IF V$FUNCTION EQ 'E' OR V$FUNCTION EQ 'L' THEN 046 CALL FUNCTION.DISPLAY 047 V$FUNCTION = '' 048 END 049 050 END ELSE 051 052 GOSUB CHECK.ID ; * Special Editing of ID 053 IF V$ERROR THEN GOTO MAIN.REPEAT 054 055 CALL RECORD.READ 056 057 IF MESSAGE EQ 'REPEAT' THEN 058 GOTO MAIN.REPEAT 059 END 060 061 GOSUB CHECK.RECORD ; * Special Editing of Record 062 063 CALL MATRIX.ALTER 064 065 IF V$ERROR THEN GOTO MAIN.REPEAT 066 067 LOOP 068 GOSUB PROCESS.FIELDS ; * ) For Input 069 GOSUB PROCESS.MESSAGE ; * ) Applications 070 WHILE (MESSAGE EQ 'ERROR') REPEAT 071 072 END 073 074 MAIN.REPEAT: 075 REPEAT 076 077 V$EXIT: 078 RETURN ; * From main program 079 080 ************************************************************************* 081 * S u b r o u t i n e s * 082 ************************************************************************* 083 084 PROCESS.FIELDS: 085 086 * Input or display the record fields. 087 088 LOOP 089 IF SCREEN.MODE EQ 'MULTI' THEN 090 IF FILE.TYPE EQ 'I' THEN 091 CALL FIELD.MULTI.INPUT 092 END ELSE 093 CALL FIELD.MULTI.DISPLAY 094 END 095 END ELSE 096 IF FILE.TYPE EQ 'I' THEN 097 CALL FIELD.INPUT 098 END ELSE 099 CALL FIELD.DISPLAY 100 END 101 END 102 103 WHILE NOT(MESSAGE) 104 105 GOSUB CHECK.FIELDS ; * Special Field Editing 106 107 IF T.SEQU NE '' THEN T.SEQU<-1> = A + 1 108 109 REPEAT 110



111 RETURN 112 113 ************************************************************************* 114 115 PROCESS.MESSAGE: 116 117 * Processing after exiting from field input (PF5) 118 119 IF MESSAGE = 'DEFAULT' THEN 120 MESSAGE = 'ERROR' ; * Force the processing back 121 IF V$FUNCTION <> 'D' AND V$FUNCTION <> 'R' THEN 122 GOSUB CROSS.VALIDATION 123 END 124 END 125 126 IF MESSAGE = 'PREVIEW' THEN 127 MESSAGE = 'ERROR' ; * Force the processing back 128 IF V$FUNCTION <> 'D' AND V$FUNCTION <> 'R' THEN 129 GOSUB CROSS.VALIDATION 130 IF NOT(V$ERROR) THEN 131 REM > GOSUB DELIVERY.PREVIEW ; * Activate print preview 132 END 133 END 134 END 135 136 IF MESSAGE EQ 'VAL' THEN 137 MESSAGE = '' 138 BEGIN CASE 139 CASE V$FUNCTION EQ 'D' 140 GOSUB CHECK.DELETE ; * Special Deletion checks 141 CASE V$FUNCTION EQ 'R' 142 GOSUB CHECK.REVERSAL ; * Special Reversal checks 143 CASE OTHERWISE 144 GOSUB CROSS.VALIDATION ; * Special Cross Validation 145 IF NOT(V$ERROR) THEN 146 GOSUB OVERRIDES 147 END 148 END CASE 149 IF NOT(V$ERROR) THEN 150 GOSUB BEFORE.UNAU.WRITE ; * Special Processing before write 151 END 152 IF NOT(V$ERROR) THEN 153 CALL UNAUTH.RECORD.WRITE 154 IF MESSAGE NE "ERROR" THEN 155 GOSUB AFTER.UNAU.WRITE ; * Special Processing after write 156 END 157 END 158 159 END 160 161 IF MESSAGE EQ 'AUT' THEN 162 GOSUB AUTH.CROSS.VALIDATION ; * Special Cross Validation 163 IF NOT(V$ERROR) THEN 164 GOSUB BEFORE.AUTH.WRITE ; * Special Processing before write 165 END 166 167 IF NOT(V$ERROR) THEN 168 169 CALL AUTH.RECORD.WRITE 170 171 IF MESSAGE NE "ERROR" THEN 172 GOSUB AFTER.AUTH.WRITE ; * Special Processing after write 173 END 174 END 175 176 END 177 178 RETURN



179 180 ************************************************************************* 181 * Special Tailored Subroutines * 182 ************************************************************************* 183 184 CHECK.ID: 185 * Validation and changes of the ID entered. Set ERROR to 1 if in error. 186 V$ERROR = 0 187 E = '' 188 189 IF E THEN 190 V$ERROR = 1 191 CALL ERR 192 END 193 194 RETURN 195 196 ************************************************************************* 197 198 CHECK.RECORD: 199 200 * Validation and changes of the Record. Set ERROR to 1 if in error. 201 202 * 203 * A application runnin in browser will enter CHECK.RECORD multiple 204 * times during a transaction lifecycle. Any validation that must only 205 * run when the user first opens the contract must be put in the following 206 * IF statement 207 * 208 IF OFS$STATUS<STAT.FLAG.FIRST.TIME> THEN ; * BG_100007114 209 210 END 211 212 RETURN 213 214 ************************************************************************* 215 216 CHECK.FIELDS: 217 REM > CALL XX.CHECK.FIELDS 218 IF E THEN 219 T.SEQU = "IFLD" 220 CALL ERR 221 END 222 223 RETURN 224 225 ************************************************************************* 226 227 CROSS.VALIDATION: 228 229 * 230 V$ERROR = '' 231 ETEXT = '' 232 TEXT = '' 233 * 234 REM > CALL XX.CROSSVAL 235 * 236 * If END.ERROR has been set then a cross validation error has occurred 237 * 238 IF END.ERROR THEN 239 A = 1 240 LOOP UNTIL T.ETEXT<A> <> "" DO A = A+1 ; REPEAT 241 T.SEQU = "D" 242 T.SEQU<-1> = A 243 V$ERROR = 1 244 MESSAGE = 'ERROR' 245 END 246 RETURN ; * Back to field input via UNAUTH.RECORD.WRITE



247 248 ************************************************************************* 249 250 OVERRIDES: 251 * 252 * Overrides should reside here. 253 * 254 V$ERROR = '' 255 ETEXT = '' 256 TEXT = '' 257 REM > CALL XX.OVERRIDE 258 * 259 260 * 261 IF TEXT = "NO" THEN ; * Said NO to override 262 V$ERROR = 1 263 MESSAGE = "ERROR" ; * Back to field input 264 265 END 266 RETURN 267 268 ************************************************************************* 269 270 AUTH.CROSS.VALIDATION: 271 272 273 RETURN 274 275 ************************************************************************* 276 277 CHECK.DELETE: 278 279 280 RETURN 281 282 ************************************************************************* 283 284 CHECK.REVERSAL: 285 286 287 RETURN 288 289 ************************************************************************* 290 DELIVERY.PREVIEW: 291 292 RETURN 293 294 ************************************************************************* 295 296 BEFORE.UNAU.WRITE: 297 * 298 * Contract processing code should reside here. 299 * 300 REM > CALL XX. ;* Accounting, Schedule processing etc etc 301 302 IF TEXT = "NO" THEN ; * Said No to override 303 CALL TRANSACTION.ABORT ; * Cancel current transaction 304 V$ERROR = 1 305 MESSAGE = "ERROR" ; * Back to field input 306 RETURN 307 END 308 309 * 310 * Additional updates should be performed here 311 * 312 REM > CALL XX... 313 314



315 316 RETURN 317 318 ************************************************************************* 319 320 AFTER.UNAU.WRITE: 321 322 323 RETURN 324 325 ************************************************************************* 326 327 AFTER.AUTH.WRITE: 328 329 330 RETURN 331 332 ************************************************************************* 333 334 BEFORE.AUTH.WRITE: 335 336 BEGIN CASE 337 CASE R.NEW(V-8)[1,3] = "INA" ; * Record status 338 REM > CALL XX.AUTHORISATION 339 CASE R.NEW(V-8)[1,3] = "RNA" ; * Record status 340 REM > CALL XX.REVERSAL 341 342 END CASE 343 344 RETURN 345 346 ************************************************************************* 347 348 CHECK.FUNCTION: 349 350 * Validation of function entered. Set FUNCTION to null if in error. 351 352 IF INDEX('V',V$FUNCTION,1) THEN 353 E = 'EB.RTN.FUNT.NOT.ALLOWED.APP' 354 CALL ERR 355 V$FUNCTION = '' 356 END 357 358 RETURN 359 360 ************************************************************************* 361 362 INITIALISE: 363 364 RETURN 365 366 ************************************************************************* 367 368 DEFINE.PARAMETERS: 369 * SEE 'I_RULES' FOR DESCRIPTIONS * 370 371 REM > CALL XX.FIELD.DEFINITIONS 372 373 RETURN 374 375 ************************************************************************* 376 377 END



TEMPLATE.L 001 * Version 6 22/05/01 GLOBUS Release No. 200505 22/04/05 002 003 SUBROUTINE TEMPLATE.L 004 005 ********************************************************************* 006 007 ********************************************************************** 008 * 02/09/02 - GLOBUS_EN_10001055 009 * Conversion Of all Error Messages to Error Codes 010 ********************************************************************* 011 $INSERT I_COMMON 012 $INSERT I_EQUATE 013 $INSERT I_F.ACCOUNT ;* Other Inserts required for Checkfiles, etc. 014 $INSERT I_F.CUSTOMER 015 $INSERT I_F.SEC.ACC.MASTER 016 017 ************************************************************************* 018 019 GOSUB INITIALISE ; * Special Initialising 020 021 GOSUB DEFINE.PARAMETERS 022 023 IF LEN(V$FUNCTION) GT 1 THEN 024 GOTO V$EXIT 025 END 026 027 CALL MATRIX.UPDATE 028 029 030 ************************************************************************* 031 032 * Main Program Loop 033 034 LOOP 035 036 CALL RECORDID.INPUT 037 038 UNTIL MESSAGE = 'RET' DO 039 040 V$ERROR = '' 041 042 IF MESSAGE = 'NEW FUNCTION' THEN 043 044 GOSUB CHECK.FUNCTION ; * Special Editing of Function 045 046 IF V$FUNCTION EQ 'E' OR V$FUNCTION EQ 'L' THEN 047 CALL FUNCTION.DISPLAY 048 V$FUNCTION = '' 049 END 050 051 END ELSE 052 053 GOSUB CHECK.ID ; * Special Editing of ID 054 IF V$ERROR THEN GOTO MAIN.REPEAT 055 056 CALL RECORD.READ 057 058 IF MESSAGE = 'REPEAT' THEN 059 GOTO MAIN.REPEAT 060 END



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



128 RETURN 129 130 ************************************************************************* 131 132 DEFINE.PARAMETERS:* SEE 'I_RULES' FOR DESCRIPTIONS * 133 134 135 MAT F = "" ; MAT N = "" ; MAT T = "" 136 MAT CHECKFILE = "" ; MAT CONCATFILE = "" 137 ID.CHECKFILE = "" ; ID.CONCATFILE = "" 138 139 ID.F = "KEY" ; ID.N = "___" ; ID.T = "_" 140 * 141 Z=0 142 * 143 REM > Z+=1 ; F(Z) = "XX.XX.FIELD.NAME" ; N(Z) = "35.2" ; T(Z) = "A" 144 REM > CHECKFILE(Z) = CHK.ACCOUNT 145 * 146 147 * 148 * Live files DO NOT require V = Z + 9 as there are not audit fields. 149 * But it does require V to be set to the number of fields 150 * 151 152 V = Z 153 154 RETURN 155 156 ************************************************************************* 157 158 END

TEMPLATE.T 001 * Version 5 02/06/00 GLOBUS Release No. G15.0.01 31/08/04 002 003 SUBROUTINE TEMPLATE.T 004 005 *MODIFICATIONS 006 ************************************************************************* 007 *18/05/00 - GB0001261 008 * Jbase changes. 009 * All the commented lines containing the keyword ERROR 010 * has been changed to V$ERROR 011 012 * 013 * 02/09/02 - GLOBUS_EN_10001055 014 * Conversion Of all Error Messages to Error Codes 015 * 016 *MODIFICATIONS 017 ***************************************************************** 018 *18/05/00 - GB0001261 019 * Jbase changes. 020 * All commented lines containing the key word ERROR has been 021 * changed to V$ERROR. 022 023 $INSERT I_COMMON 024 $INSERT I_EQUATE 025 026 ************************************************************************* 027 028 GOSUB DEFINE.PARAMETERS 029 030 IF LEN(V$FUNCTION) GT 1 THEN 031 GOTO V$EXIT 032 END



033 034 CALL MATRIX.UPDATE 035 036 REM > GOSUB INITIALISE ;* Special Initialising 037 038 ************************************************************************* 039 040 * Main Program Loop 041 042 LOOP 043 044 CALL RECORDID.INPUT 045 046 UNTIL MESSAGE = 'RET' DO 047 048 V$ERROR = '' 049 050 IF MESSAGE = 'NEW FUNCTION' THEN 051 052 GOSUB CHECK.FUNCTION ; * Special Editing of Function 053 054 IF V$FUNCTION EQ 'E' OR V$FUNCTION EQ 'L' THEN 055 CALL FUNCTION.DISPLAY 056 V$FUNCTION = '' 057 END 058 059 END ELSE 060 061 REM > GOSUB CHECK.ID ;* Special Editing of ID 062 REM > IF V$ERROR THEN GOTO MAIN.REPEAT 063 064 CALL RECORD.READ 065 066 IF MESSAGE = 'REPEAT' THEN 067 GOTO MAIN.REPEAT 068 END 069 070 CALL MATRIX.ALTER 071 072 CALL TABLE.DISPLAY ; * For Table Files 073 074 END 075 076 MAIN.REPEAT: 077 REPEAT 078 079 V$EXIT: 080 RETURN ; * From main program 081 082 ************************************************************************* 083 * Special Tailored Subroutines * 084 ************************************************************************* 085 086 CHECK.ID: 087 088 * Validation and changes of the ID entered. Set ERROR to 1 if in error. 089 090 091 RETURN 092 093 094 ************************************************************************* 095 096 CHECK.FUNCTION: 097 098 * Validation of function entered. Set FUNCTION to null if in error. 099 100 IF INDEX('V',V$FUNCTION,1) THEN



101 E ='EB.RTN.FUNT.NOT.ALLOWED.APP.17' 102 CALL ERR 103 V$FUNCTION = '' 104 END 105 106 RETURN 107 108 ************************************************************************* 109 110 INITIALISE: 111 112 113 RETURN 114 115 ************************************************************************* 116 117 DEFINE.PARAMETERS:* SEE 'I_RULES' FOR DESCRIPTIONS * 118 119 120 MAT F = "" ; MAT N = "" ; MAT T = "" 121 MAT CHECKFILE = "" ; MAT CONCATFILE = "" 122 ID.CHECKFILE = "" ; ID.CONCATFILE = "" 123 124 REM > ID.F = "Key.Description"; ID.N = "____"; ID.T = "_" 125 REM > ID.CHECKFILE = "Main.File.Name" : FM : Enrichment.Field 126 127 REM > F(1) = "XX.LL.Index.Description"; N(1) = "35.3" 128 REM > CHECKFILE(1) = "Indexed.File.Name" : FM : Enrichment.Field 129 130 RETURN 131 132 ************************************************************************* 133 134 END

TEMPLATE.W 001 * Version 8 02/06/00 GLOBUS Release No. G15.0.01 31/08/04 002 003 SUBROUTINE TEMPLATE.W 004 * 005 * MODIFICATIONS 006 * 007 *18/05/00 - GB0001261 008 * The keyword ERROR in all the commented statements has been 009 * changed to V$ERROR. 010 * 011 * 02/09/02 - GLOBUS_EN_10001055 012 * Conversion Of all Error Messages to Error Codes 013 ************************************************************************* 014 $INSERT I_COMMON 015 $INSERT I_EQUATE 016 $INSERT I_SCREEN.VARIABLES 017 018 ************************************************************************* 019 020 * Call $RUN Routine and Exit if running as Phantom * 021 022 IF PHNO THEN 023 REM > CALL TEMPLATE.W$RUN 024 GOTO V$EXIT 025 END 026 027 ************************************************************************* 028 029 GOSUB DEFINE.PARAMETERS



030 031 IF LEN(V$FUNCTION) GT 1 THEN 032 GOTO V$EXIT 033 END 034 035 CALL MATRIX.UPDATE 036 037 REM > GOSUB INITIALISE ;* Special Initialising 038 039 ************************************************************************* 040 041 * Main Program Loop 042 043 LOOP 044 045 CALL RECORDID.INPUT 046 047 UNTIL MESSAGE = 'RET' DO 048 049 V$ERROR = '' 050 051 IF MESSAGE = 'NEW FUNCTION' THEN 052 053 GOSUB CHECK.FUNCTION ; * Special Editing of Function 054 055 IF V$FUNCTION EQ 'L' THEN 056 CALL FUNCTION.DISPLAY 057 V$FUNCTION = '' 058 END 059 IF V$FUNCTION EQ 'V' THEN 060 FILE.TYPE = "I" 061 END 062 063 END ELSE 064 065 GOSUB CHECK.ID ; * Special Editing of ID 066 IF V$ERROR THEN GOTO MAIN.REPEAT 067 068 CALL RECORD.READ 069 070 IF MESSAGE = 'REPEAT' THEN 071 GOTO MAIN.REPEAT 072 END 073 074 CALL MATRIX.ALTER 075 076 REM > GOSUB CHECK.RECORD ;* Special Editing of Record 077 REM > IF V$ERROR THEN GOTO MAIN.REPEAT 078 079 REM > GOSUB PROCESS.DISPLAY ;* For Display applications 080 081 LOOP 082 GOSUB PROCESS.FIELDS ; * ) For Input 083 GOSUB PROCESS.MESSAGE ; * ) Applications 084 WHILE MESSAGE = 'ERROR' DO REPEAT 085 086 END 087 088 MAIN.REPEAT: 089 REPEAT 090 091 V$EXIT: 092 RETURN ; * From main program 093 094 ************************************************************************* 095 * S u b r o u t i n e s * 096 ************************************************************************* 097



098 PROCESS.FIELDS: 099 100 * Input or display the record fields. 101 102 LOOP 103 104 IF SCREEN.MODE EQ 'MULTI' THEN 105 IF FILE.TYPE EQ 'I' THEN 106 CALL FIELD.MULTI.INPUT 107 END ELSE 108 CALL FIELD.MULTI.DISPLAY 109 END 110 END ELSE 111 IF FILE.TYPE EQ 'I' THEN 112 CALL FIELD.INPUT 113 END ELSE 114 CALL FIELD.DISPLAY 115 END 116 END 117 118 UNTIL MESSAGE <> "" DO 119 120 REM > GOSUB CHECK.FIELDS ;* Special Field Editing 121 122 IF T.SEQU NE '' THEN T.SEQU<-1> = A + 1 123 124 REPEAT 125 126 RETURN 127 128 ************************************************************************* 129 130 PROCESS.MESSAGE: 131 132 * Processing after exiting from field input (PF5) 133 134 IF MESSAGE = 'VAL' OR MESSAGE EQ 'VER' THEN 135 MESSAGE = '' 136 BEGIN CASE 137 CASE V$FUNCTION EQ 'R' 138 END.ERROR = "" 139 REM > GOSUB CHECK.REVERSAL ;* Special Reversal checks 140 CASE V$FUNCTION EQ 'V' 141 REM > GOSUB CHECK.VERIFY ;* Special Verify checks 142 GOSUB CHECK.CHANGES ; * look for changed field 143 IF YWRITE EQ 0 AND NOT(END.ERROR) THEN 144 GOSUB CALL.$RUN ; * update using $RUN 145 GOTO PROCESS.MESSAGE.EXIT ; * and return to Id input 146 END 147 CASE OTHERWISE 148 REM > GOSUB AUTH.CROSS.VALIDATION ;* Special Cross Validation 149 END CASE 150 151 IF END.ERROR THEN 152 GOSUB POINT.TO.ERROR ; * position on error field 153 GOTO PROCESS.MESSAGE.EXIT ; * return to field input 154 END 155 156 REM > IF NOT(V$ERROR) THEN 157 REM > GOSUB BEFORE.AUTH.WRITE ;* Special Processing before write 158 REM > END 159 160 IF NOT(V$ERROR) THEN 161 CALL AUTH.RECORD.WRITE 162 163 IF MESSAGE <> "ERROR" THEN 164 REM > GOSUB AFTER.AUTH.WRITE ;* Special Processing after write 165



166 IF V$FUNCTION EQ 'V' THEN 167 GOSUB CALL.$RUN 168 END 169 170 END 171 172 END 173 174 END 175 176 PROCESS.MESSAGE.EXIT: 177 178 RETURN 179 180 ************************************************************************* 181 182 PROCESS.DISPLAY: 183 184 * Display the record fields. 185 186 IF SCREEN.MODE EQ 'MULTI' THEN 187 CALL FIELD.MULTI.DISPLAY 188 END ELSE 189 CALL FIELD.DISPLAY 190 END 191 192 RETURN 193 194 ************************************************************************* 195 196 CHECK.CHANGES: 197 198 YWRITE = 0 199 IF END.ERROR EQ '' THEN 200 A = 1 201 LOOP UNTIL A GT V OR YWRITE DO 202 IF R.NEW(A) NE R.OLD(A) THEN YWRITE = 1 ELSE A += 1 203 REPEAT 204 END 205 206 RETURN 207 208 ************************************************************************* 209 210 POINT.TO.ERROR: 211 212 IF END.ERROR EQ 'Y' THEN 213 P = 0 ; A = 1 214 LOOP UNTIL T.ETEXT<A> NE '' DO 215 A += 1 216 REPEAT 217 T.SEQU = A 218 IF SCREEN.MODE EQ 'SINGLE' THEN 219 IF INPUT.BUFFER[1,LEN(C.F)] EQ C.F THEN 220 INPUT.BUFFER = INPUT.BUFFER[LEN(C.F) + 2,99] 221 ; * cancel C.F function after C.W usage 222 ; * (+2 for space separator) 223 END 224 END ELSE 225 E = T.ETEXT<A> 226 CALL ERR 227 END 228 END ELSE 229 T.SEQU = 'ACTION' ; E = END.ERROR ; L = 22 230 CALL ERR 231 END 232 233 CALL DISPLAY.MESSAGE("", "1") ; * Clear the VALIDATED message



234 VAL.TEXT = "" 235 MESSAGE = 'ERROR' 236 237 RETURN 238 239 ************************************************************************* 240 241 CALL.$RUN: 242 243 * Process the 'Work' file using the $Run Routine * 244 245 V$FUNCTION = FUNCTION.SAVE 246 247 REM > CALL TEMPLATE.W$RUN 248 249 IF V$FUNCTION EQ 'B' THEN 250 V$FUNCTION = 'V' 251 END 252 253 RETURN 254 255 ************************************************************************* 256 * Special Tailored Subroutines * 257 ************************************************************************* 258 259 CHECK.ID: 260 261 * Validation and changes of the ID entered. Set ERROR to 1 if in error. 262 263 264 RETURN 265 266 ************************************************************************* 267 268 CHECK.RECORD: 269 270 * Validation and changes of the Record. Set ERROR to 1 if in error. 271 272 273 RETURN 274 275 ************************************************************************* 276 277 CHECK.FIELDS: 278 279 280 RETURN 281 282 ************************************************************************* 283 284 AUTH.CROSS.VALIDATION: 285 286 287 RETURN 288 289 ************************************************************************* 290 291 CHECK.REVERSAL: 292 293 294 RETURN 295 296 ************************************************************************* 297 298 CHECK.VERIFY: 299 300 301 RETURN



302 303 ************************************************************************* 304 305 AFTER.AUTH.WRITE: 306 307 308 RETURN 309 310 ************************************************************************* 311 312 BEFORE.AUTH.WRITE: 313 314 315 RETURN 316 317 ************************************************************************* 318 319 CHECK.FUNCTION: 320 321 * Validation of function entered. Set FUNCTION to null if in error. 322 323 FUNCTION.SAVE = V$FUNCTION 324 IF V$FUNCTION EQ "B" THEN 325 V$FUNCTION = "V" 326 ID.ALL = "" 327 END 328 IF INDEX('ADEFQ',V$FUNCTION,1) THEN 329 E ='EB.RTN.FUNT.NOT.ALLOWED.APP.17' 330 CALL ERR 331 V$FUNCTION = '' 332 END 333 334 RETURN 335 336 ************************************************************************* 337 338 INITIALISE: 339 340 341 RETURN 342 343 ************************************************************************* 344 345 DEFINE.PARAMETERS:* SEE 'I_RULES' FOR DESCRIPTIONS * 346 347 348 MAT F = "" ; MAT N = "" ; MAT T = "" 349 MAT CHECKFILE = "" ; MAT CONCATFILE = "" 350 ID.CHECKFILE = "" ; ID.CONCATFILE = "" 351 352 REM > ID.F = "KEY"; ID.N = "____"; ID.T = "_" 353 REM > F(1) = "XX.LL.DESCRIPTION"; N(1) = "35.3"; T(1) = "A" 354 355 REM > V = NumberOfFields + 9 356 357 RETURN 358 359 ************************************************************************* 360 361 END


TEMENOS T24 Template Programming - MarkMail

Documents

Transcript of TEMENOS T24 Template Programming - MarkMail