Version Routines and API

T24 Technical Training
APPLICATION
PROGRAMMING
INTERFACES
Application Program Interfaces
Page 1 of 25

APPLICATION PROGRAM INTERFACES
1.1
Introduction
This chapter describes the available options for developers who wish to enhance
the operation of the current GLOBUS system, where there are insufficient options
provided by the Standard GLOBUS utilities. Within specific applications the
system allows universe subroutines (or UniVerse commands in some cases) to
be defined, which will then be invoked when running the applications. This
provides a powerful tool to allow customisation of the GLOBUS to meet regional
or customer specific requirements.
1.2
APPLICATION CUSTOMISATION
1.2.1 Introduction
This section is concerned with the options available in customising the operation
and content of GLOBUS applications.
1.2.2 VERSION APPLICATION - USER DEFINED SUBROUTINES
The VERSION application allows user defined subroutines to be specified in the
following fields:
1.2.2.1
AUT.NEW.CONTENT
VALIDATION.RTN
INPUT.ROUTINE
AUTH.ROUTINE
AUT.NEW.CONTENT (Field 33.1)
This field would normally be used to automatically enter a value into a field
specified in the associated AUTOM.FIELD.NO. The automatic contents are only
used if the existing content of the field matches that defined in the associated
AUT.OLD.CONTENT. This field may also contain a sub-routine used to perform
conditional defaulting that cannot be defined in Version, or defaulting from related
files.
Page 2 of 25
The following steps must be followed:

AUTOM.FIELD.NO The name of the field that has to be automatically defaulted.
AUT.NEW.CONTENT @user-defined subroutine
User-defined subroutine must be defined in PGM.FILE as a type S application.

The field APPL.FOR.SUBR contains the applications allowed to use the
subroutine.
Example:
The following example demonstrates a routine, which will automatically assign
the industry code and industry name in the file TRN.SHARE.MASTER.
Figure 1.1 PGM.FILE For V.INDUSTRY.NAME
Figure 1.2 VERSION Automatic defaulting definition
Page 3 of 25

To default the INDUSTRY.CODE and INDUSTRY.NAME field using the routine
V.INDUSTRY.NAME.
Program :
0001:
SUBROUTINE V.INDUSTRY.NAME
0002: * Subroutine to default the value of industry code and industry name in
0003: * the application TRN.SHARE.MASTER
0004: *
0005: $INSERT I_COMMON
0006: $INSERT I_EQUATE
0007: $INSERT I_F.INDUSTRY
0008: $INSERT I_F.TRN.SHARE.MASTER
0009: *
0010:
TEMP = FIELD(ID.NEW,'-',2)
0011:
CALL DBR("INDUSTRY":FM:EB.IND.DESCRIPTION,TEMP,IND.NAME)
0012:
R.NEW(TRSM.INDUSTRY.CODE) = TEMP
0013:
R.NEW(TRSM.INDUSTRY.NAME) = IND.NAME
0014:
RETURN
0015: END
1.2.2.2
VALIDATION.RTN (Field 40.1)
This field, together with VALIDATION.FLD, allows definition of subroutines to be

executed when validating the contents of fields within an application. A routine
defined here would normally be used to perform specific validation or to default
the contents of field according to local requirements.
VALIDATION.FLD The name of the field which has to be validated.
VALIDATION.RTN user-defined subroutine
This subroutine is invoked immediately after the call to IN2xx as defined in the T
parameters for the application, and before any validation in the section
CHECK.FIELDS is executed. Also at Cross-Validation time, before the
CROSS.VALIDATION section of the application is executed.
Routines defined here have the standard system variables available for checking.
The following variables should be used when performing checks/defaults:
COMI
COMI.ENRI
DISPLAY
ETEXT
Contains the contents of specified VALIDATION.FLD.

This should contain the enrichment for the contents of COMI.
Contains the formatted version of COMI for display purposes.
Contains any error message generated from the subroutine. This
field should be populated when an error is found.
MESSAGE This variable can be used to determine whether the system is
performing field level checks or cross validation. At cross-validation
time it will contain the value VAL; on-line it will be null.
Page 4 of 25
Example :
0001: *Subroutine to check whether the trading unit is a multiple
0002: * of 12
0003: *
0004:
SUBROUTINE V.TRADE.UNIT.VAL
0005: *
0008: $INSERT I_F.TRN.SHARE.MASTER
0009: $INSERT I_F.TRN.SH.TRANSACTION
0010: *
0011: CALL DBR
(TRN.SHARE.MASTER:FM:TRSM.TRADING.UNITS,R.NEW(TRST.SHARE.ID),TU)
0012:
IF MOD (COMI, TU) NE 0 THEN
0013:
ETEXT = "Invalid multiple of TRADING UNITS"
0014:
CALL STORE.END.ERROR
0015:
RETURN
0016:
END
0017:
RETURN
0018: *
0019:
END
In the version the following are specified :
Figure 1.3
1.2.2.3
Version -Validation Routine
AUTH.ROUTINE (Field 45.1)
The subroutine may be executed at the authorization stage of transaction

processing, as the final stage before updating authorized files. Multiple routines
may be defined by expanding the multi-values. Routines called at this stage may
be used to update local files. No checking or override processing should be
performed at this stage as the system cannot process error conditions at this
point.
AUTH.ROUTINE user-defined subroutine
The user-defined subroutine used at this stage provide updates to local files.
Page 5 of 25
Example :
0001: *Subroutine to update the TRN.SHARE.HOLDING at authorization stage
0002: *
0003:
SUBROUTINE V.UPDATE.SHARE.HOLDING
0004: *
0007: $INSERT I_F.TRN.SHARE.HOLDING
0008: $INSERT I_F.TRN.SH.TRANSACTION
0009: *
0010:
GOSUB INITIALISE
0011:
GOSUB PROCESS
0012:
RETURN
0013: *
0014: INITIALISE:
0015:
FN.TRN.SHARE.HOLDING = "F.TRN.SHARE.HOLDING"
0016:
CALL OPF(FN.TRN.SHARE.HOLDING,F.TRN.SHARE.HOLDING)
0017:
K.ID = ''
0018:
R.REC = ''
0019:
RETURN
0020: *
0021: PROCESS:
0022:
CUST.ID = R.NEW(TRST.CUSTOMER.ID)
0023:
SHA.ID = R.NEW(TRST.SHARE.ID)
0024:
K.ID = SHA.ID :'/':CUST.ID
0025:
CALL F.READ("F.TRN.SHARE.HOLDING",K.ID,R.REC,F.TRN.SHARE.HOLDING,ER
)
0026:
IF R.NEW(TRST.TRANSACTION.TYPE) EQ 'PURCHASE' THEN
0027:
IF R.REC EQ '' THEN
0028:
R.REC<TRSH.CUSTOMER.ID> = R.NEW(TRST.CUSTOMER.ID)
0029:
R.REC<TRSH.SHARE.ID> = R.NEW(TRST.SHARE.ID)
0030:
R.REC<TRSH.CURR.POSITION> = R.NEW(TRST.TRANS.UNITS)
0031:
R.REC<TRSH.CURR.COST> = R.NEW(TRST.TRANS.VALUE)
0032:
R.REC<TRSH.AVG.PRICE> = R.NEW(TRST.TRANS.PRICE)
0033:
CALL F.WRITE("F.TRN.SHARE.HOLDING",K.ID,R.REC)
0034:
END ELSE
0035:
R.REC<TRSH.CURR.POSITION> += R.NEW(TRST.TRANS.UNITS)
0036:
R.REC<TRSH.CURR.COST> += R.NEW(TRST.TRANS.VALUE)
0037:
R.REC<TRSH.AVG.PRICE> = ((R.REC<TRSH.CURR.POSITION>*R.REC<TRS H.CURR.COST>) +
(R.NEW(TRST.TRANS.UNITS) * R.NEW(TRST.TRANS.VALUE)))/(R.REC<TRSH.CURR.POSITION> +
.NEW(TRST.TRANS.VALUE))
0038:
0039:
END
0040:
END ELSE
0041:
IF R.NEW(TRST.TRANSACTION.TYPE) EQ 'SALE' THEN
0042:
R.REC<TRSH.CURR.POSITION> -= R.NEW(TRST.TRANS.UNITS)
0043:
R.REC<TRSH.CURR.COST> -= R.NEW(TRST.TRANS.UNITS) * R.REC<TRSH.AVG.PRICE>
0044:
0045:
END
0046:
END
0047:
RETURN
0048: END
Figure 1.4
Version Authorization routine
Page 6 of 25
1.2.2.4
INPUT ROUTINE (Field 44.1)
A subroutine may be executed at the unauthorized stage of transaction

processing, as the final stage before updating unauthorized files. Multiple
routines may be defined by expanding the multi-values. Routines called at this
stage may be used to update local files, or to provide additional checking or
override processing. At this point of the transaction, all standard default and
validation processing will have taken place.
INPUT.ROUTINE user-defined subroutine
To run the VERSION simply enter the application name with the version
reference. SMS control can be defined specifically for the VERSION by entering
the name of the VERSION, with the comma, in USER, in the field VERSION.
Consequently you can restrict access to the records, as well as the application
itself.
Example:
Consider a version for example CUSTOMER,TEST. SMS control is defined for
the version in USER.
Figure 1.5 SMS control for version

APPLICATION
Specifies the Application used to access records belonging

to the Company specified in the related COMPANY RESTR.
Ex. CUSTOMER
VERSION
Specifies a particular Version which may be used to access

records for the Application entered in the corresponding
APPLICATION Ex. CUSTOMER,TEST
FUNCTION
Specifies the functions that may be used to access records

of the application entered in the APPLICATION field. Ex. L S
Page 7 of 25

FIELD NO
Specifies against which field the condition is to be met. Ex

Nationality (15)
DATA.COMPARISON Specifies the type of comparison to be made between the

contents of the field indicated in FIELD.NO and the values
specified in DATA.FROM and DATA.TO. Ex. EQ
DATA.FROM
Specifies the value, or start of a range of values, with which

the contents of the field indicated in FIELD NO are to be
compared with. Ex US
DATA.TO
Specifies the end of a range of values with which the

contents of the field indicated in FIELD NO are to be
compared with.
The version CUSTOMER,TEST limits the user to listing and seeing only those
records of the customer application where the nationality is US.
1.2.3 OVERRIDE.CLASS.DETAILS
OVERRIDE.CLASS.DETAILS allows a subroutine to be defined to manipulate an
override message so that the conditions defined in this table may be applied to it.
For example, an overdraft message could be converted into local currency for
allocating an override class depending on the amount.
1.2.4 PGM.FILE
The PGM.FILE has several uses for developers wishing to customise GLOBUS.
Definition of Subroutines to be used in applications

Definition of new applications to be run on-line
Definition of routines which may be run in the batch
1.2.4.1 PROGRAM (ID)

For on-line applications the key to this record must be the same as the program
to be run.
Format: Subroutine name
Subroutine name is the name of the application, which can be invoked. The field
TYPE indicates the application type to be executed. For on-line use this may
H,U,L,T,W or M. This is invoked from RUN.APPLICATION
Any application of types H,U,L,T or W are used to maintain a file and must
conform to the standard TEMPLATE application type.
Type M routines are used to execute a specific main line program where there is
no standard file maintenance required, for example a conversion program, or
Page 8 of 25

program to print a report. Where a history is required of a program being run, a
type W program should be used.
When a type M program is written, it must contain a SUBROUTINE statement at
the start in order to return to GLOBUS once executed.
Example: The type M program SB.LIST.LOCKs allows an operator to list the
active system locks.
The program for SB.LIST.LOCKS is as follows:
0001:
SUBROUTINE SB.LIST.LOCKS
0002: *
0003: * This program performs the LIST.READU command
0004: *
0005:
EXECUTE "CS" ; * Clear Screen
0006:
EXECUTE "LIST.READU"
0007:
CRT "Press Return TO Return to GLOBUS":
0008:
INPUT WAIT
0009:
RETURN
0010: *
0011: END
The PGM.FILE record for SB.LIST.LOCKS is as follows:
The result of execution of SB.LIST.LOCKS subroutine at GLOBUS Action prompt

is as follows:
Page 9 of 25
1.2.4.2 BATCH.JOB
This field is used to define the names of subroutines, or UniVerse commands,
which may be executed from the GLOBUS BATCH.CONTROL process. To be
executed during the end of day the BATCH.JOB must be defined on a BATCH
record.
Format: @Subroutine name or UniVerse Command
Subroutine name is the name of the application, which can be invoked.
Universe Command is the name of the item defined in the local VOC file to be
executed.
This is a multi-valued field, and several subroutines and or commands may be
executed sequentially. This is invoked from B.INITIATE.PROCESS. A subroutine
may be written to perform specific end of day processing. This may have a
variety of functions, such as maintenance of local files/applications, production of
reports, interface file production etc.
A UniVerse command, or paragraph can also be executed from this option. Any
item recognised in the VOC file of the correct type may be executed.
Page 10 of 25
1.2.4 BATCH.CONTROL
API calls like subroutine, script, crystal report or enquiry can be run at the pre
batch stage. Multiple calls may be defined by expanding the multi-values.
It has to be defined in VOC
SPT Script Name
It has to be defined in F.SCRIPT.DESIGNER
RPT Report Name
It has to be defined in F.REPORT.CONTROL and it has to be a crystal report.
ENQ Enquiry Name
It has to be defined in F.ENQUIRY
This is a multi-valued field and several API calls may be executed sequentially.
This is invoked from BATCH.CONTROL. This routine is called just before control
passes to the batch menu.
1.3
SYSTEM MANAGEMENT CUSTOMISATION
1.3.1 Introduction
This section contains details of options available to users for customisation of
system management. This includes the ability to be able to define commands (or
executable programs) to perform system backups as part of the end of day
process.
1.3.2 SPF
The SPF file allows definition of the command(s) used to perform the system
backup and restore at end of day.
1.3.2.1
UNIX BACKUP and UNIX RESTORE
These fields allow definition of the UNIX backup and restore commands to be
executed when the end of day process is run.
Format: UNIX command name
UNIX command name may contain any UNIX command(s) to be executed. It
may also contain a shell script. This is invoked from SYSTEM.BACKUP and
SYSTEM.RESTORE
1.4
REPORTING / ENQUIRY CUSTOMISATION
Page 11 of 25
1.4.1 Introduction
The GLOBUS utilities REPGEN and ENQUIRY provide several APIs for users
who wish to perform operations on data outside the delivered functionality.
GLOBUS also provides options for users to redirect output from reports or microfiches, which could include definition of their own subroutines.
1.4.2 ENQUIRY
The ENQUIRY application provides three main areas where local routines may
be added to provide additional functionality. These are:
Selection of data where criteria cannot be easily specified within the
existing application (this will be covered under STANDARD.SELECTION)
CONVERSION routines to manipulate/enhance data to required format
BUILD.ROUTINE to build initial data to base enquiry.
1.4.2.1 CONVERSION
Local conversion routines may be written to manipulate extracted data.
Format: @ subroutine name
Subroutine name is the name of the Universe subroutine to be executed. Note
the required space between @ and the name. This is invoked from
ENQ.BUILD.PAGE for each item the conversion is associated with.
The enquiry system has its own common area I_ENQUIRY.COMMON which
must be inserted at the start of all conversion routines. This allows access to the
variables controlling the enquiry processing.
The following variables are the most likely ones to be required when writing a
conversion routine:
ID
Current id of the record being processed
R.RECORD The current record being processed
O.DATA
The current incoming data being processed. This is also the
returned data.
VC
The current multi-value number being processed
S
The current sub-value number
VM.COUNT The maximum number of multi-values within the current record
SM.COUNT The maximum number of sub-values within the current record
Page 12 of 25

Example:
The following example shows a routine, which displays either the actual maturity
date of an LD/MM deal, or displays the number of days notice:
1.4.2.2
BUILD.ROUTINE
A routine may be called prior to the selection phase of the enquiry when running
the enquiry. This routine should be used to manipulate the data prior to selection,
for instance it could be used to build a work file.
Subroutine name is the name of the Universe subroutine to be executed. More
than one routine may be specified. This is invoked from T.ENQUIRY.SELECT and
S.ENQUIRY.SELCTION. It uses one argument - ENQ, where ENQ is a dynamic
array containing the entered selection criteria as follows:
ENQ<1>
ENQ<2,x>
ENQ<3,x>
ENQ<4,x,y>
Name of enquiry
Selection field names
Associated Operands
Data List
The data passed in ENQ should be used within the subroutine to determine the
action to be taken. No data is required to be returned to the enquiry system.
1.4.2.3
EXTERNAL LINK TO ENQUIRIES
Page 13 of 25

The enquiry system is not dependent on being invoked by the selection screen
ENQ. It can be invoked from applications (providing they are running under
GLOBUS) using the following argument syntax:
CALL ENQUIRY.DISPLAY (QQQ)
where QQQ is a dynamic array with the format:
QQQ<1>
Enquiry name (key to F.ENQUIRY)
QQQ<2,x> Selection field names
QQQ<3,x> Associated selection operands
QQQ<4,x,y> Associated selection data
QQQ<9,z> Multi valued list of sort requirements
QQQ<10> Display mode It can be:
OUTPUT
Print in report format
Null
Display to screen
P
Print of screen format
1.4.3 STANDARD SELECTION
The STANDARD.SELECTION application allows definition of local subroutines,
which can be used as selection items in the Enquiry system. These can be used
within enquiry to perform selections of data not possible through the existing
system. They can also be used to build virtual records containing data from
different files; this can be achieved using a NOFILE record type.
1.4.3.1
SYS.FIELD.NO and USR.FIELD.NO
These fields are used to hold the routine name when the associated SYS.TYPE
or USR.TYPE is a type R.
Subroutine name is the name of the subroutine to be executed. This is invoked
from CONCAT.LIST.PROCESSOR
Arguments: RTN.LIST
where RTN.LIST is a dynamic array containing the selected keys to be returned
to the enquiry system, separated by field markers (@FM).
The main purpose of using a routine at this point is to return a list of keys for the
enquiry process to use. Possible reasons for using a routine may be, the
selection required might not be possible to enter directly in the enquiry system;
require additional checks are required; the selection may simply be too slow and
requires an alternative access method.
Since the routine will need to use the common enquiry variables, the insert
I_ENQUIRY.COMMON should always be inserted at the top of the subroutine.
The main variables likely to be required are:
Page 14 of 25
D.FIELDS<X>
D.LOGICAL.OPERANDS<X>
D.RANGE.AND.VALUE<X,Y>
Contains a list of the Selection Field Names

Contains a list of the associated operands
entered in numeric form. The following values
are used:
1
EQ
2
RG
3
LT
4
GT
5
NE
6
LK
7
UL
8
LE
9
GE
10
NR
11
Associated entered values.
The routine must perform the required processing to build the RTN.LIST. Note
that if this routine is being used to pre-select data ready for a further selection
within the enquiry system, if no records are returned, the enquiry system will
attempt to select the whole file. This may have performance implications.
1.4.3.2
NOFILE Standard Selection Records
If the information that needs to be presented in an enquiry does not exists in the
single file, then the enquiry can be made to take information form routines. To do
this first let us understand the way in which enquiry subsystem works.
The enquiry subsystem first builds up list of IDs, then pickup each ID and
constructs a record and then displays the records. If the information needs to
present does not exists in a file then subroutine can be written to do the task.
Basically 2 routines needs to be written - One which will construct the list of IDs
and one which will accept the ID and build the record based on ID.
If the field is specified in an enquiry the type and position of the field is retrieved
from the standard selection record of the file mentioned in the FILE.NAME.
Standard selection is an application that basically stores the dictionary for a file.
You could have data fields and logical fields (i.e. the information is a calculated
value for e.g. from a subroutine). However generally when you try to input a
standard selection record it will validate if a FILE.CONTROL record exists for the
file. The only exception to this is if the SS record id begins with NOFILE. So for
our above requirement we will need to create an SS record with ID starting with
NOFILE. In the record for the ID field make it an R type field and attach a
routine that would build a dynamic array of ids that need to be displayed in the
enquiry.
Page 15 of 25
I_ENQUIRY.COMMON, a common file that is used in enquires defines a

variable called O.DATA which contains the ID of the record that is currently going
to be displayed. Another common variable called R.RECORD (a dynamic array)
is used by the enquiry subsystem to display the record. So you need to write a
routine that would use the id defined in O.DATA and populate R.RECORD.
Step1: Write the routine mentioned bellow.
SUBROUTINE NOFILE.ROUTINE(Y.ID.LIST)
*
$INSERT I_COMMON
$INSERT I_EQUATE
$INSERT I_F.CUSTOMER
$INSERT I_ENQUIRY.COMMON
*----------------------------------------------------------------------MAIN.PARA:
*=========
*
LOCATE "CUSTOMER.CODE" IN D.FIELDS<1> SETTING YCUST.POS ELSE
RETURN
*
IF D.LOGICAL.OPERANDS<YCUST.POS> = '' THEN RETURN
GOSUB OPEN.REQD.FILES
GOSUB LIST.CUST.NOS
*
Y.ID.LIST = Y.CUST.ARRAY
RETURN
*
*----------------------------------------------------------------------*
OPEN.REQD.FILES:
*===============
*
F.CUSTOMER = ''
FN.CUSTOMER = 'F.CUSTOMER'
CALL OPF(FN.CUSTOMER,F.CUSTOMER)
*
RETURN
*--------------------------------------------------------------------*
LIST.CUST.NOS:
*=============
Y.CUST.ARRAY = ''
Y.SEL.SET = ''
Y.EXEC = ''
Y.X = ''
YCUST.LIST = ""
*
Y.OPERAND = D.LOGICAL.OPERANDS<YCUST.POS>
Y.CHK.VALUE = D.RANGE.AND.VALUE<YCUST.POS>
Page 16 of 25

*
IF Y.OPERAND = 1 THEN
Y.I = 0
Y.I += 1
Y.CUST.ID = Y.CHK.VALUE<1,1,Y.I>
READ Y.CUST.REC FROM F.CUSTOMER, Y.CUST.ID ELSE Y.CUST.REC = ''
IF Y.CUST.REC THEN
Y.CUST.ARRAY<-1> = Y.CUST.ID
END
END
IF Y.OPERAND = 5 THEN
Y.I = 1
Y.X = Y.CHK.VALUE<1,1,Y.I>
Y.SEL.SET = ' SSELECT ': FN.CUSTOMER
CALL EB.READLIST(Y.SEL.SET,SEL.LIST,"",NO.OF.REC,ERR1)
LOOP
REMOVE FIRST.ID FROM SEL.LIST SETTING POS
WHILE FIRST.ID:POS
IF FIRST.ID NE Y.X THEN
Y.CUST.ARRAY<-1> = FIRST.ID
END
REPEAT
END
RETURN
*---------------------------------------------------------END
Step2: Write another routine to invoke within enquiry.

SUBROUTINE ACT.BAL
$INSERT
$INSERT
$INSERT
$INSERT
$INSERT
I_COMMON
I_EQUATE
I_ENQUIRY.COMMON
I_F.CUSTOMER
I_F.ACCOUNT
FN.ACCOUNT = "F.ACCOUNT"
CALL OPF(FN.ACCOUNT,F.ACCOUNT)
TOT = 0
IF O.DATA NE '' THEN
SEL.REC = "SELECT ": FN.ACCOUNT
SEL.REC := " WITH CUSTOMER EQ ":O.DATA
SEL.REC := " TO 1"
CALL !HUSHIT(1)
EXECUTE SEL.REC
CALL !HUSHIT(0)
LOOP
READNEXT K.RECORD FROM 1 ELSE K.RECORD = ''
WHILE K.RECORD DO
READ R.RECORD FROM F.ACCOUNT, K.RECORD ELSE R.RECORD = ''
Page 17 of 25

IF R.RECORD THEN
TOT = TOT + R.RECORD<AC.ONLINE.ACTUAL.BAL>
END
REPEAT
O.DATA = TOT
END
RETURN
END
Step3: Create new Standard Selection record with the following details.
Routine Name
Page 18 of 25

Step4: Create enquiry with the following details.
1.4.4 REPGEN.CREATE
The repgen utility allows use of subroutines in two areas:
MODIFICATION
FL.DECISION.FR
1.4.4.1 FL.DECISION.FR
Repgen allows a subroutine to be entered to perform a selection. The value SUB
must be entered in FL.DECISION to indicate that this field contains a sub-routine
definition.
Subroutine name is the name of the subroutine to be executed. Only one
subroutine may be defined per read file. The subroutine name must be defined
on PGM.FILE file as a type S application. This is invoked from RGS.... program
generated. It uses the argument FILENAME, which is the full filename to be
selected.
The routine should perform the required selection of the FILENAME supplied and
return an ACTIVE select list to the RGS... program. The REPGEN.SORT record
is available in R.NEW, and may contain specified values in the fields
CONSTANTS.
1.4.4.2 MODIFICATION
Page 19 of 25

The MODIFICATION field allows a sub-routine to be called to manipulate the
extracted data.
Format: @ Subroutine name#n
Subroutine name is the name of the Universe subroutine to be executed. #n
denotes the argument number in the call to the subroutine. The subroutine must
be defined in PGM.FILE as a type R routine, together with the required number
of parameters in field ADDITIONAL.INFO as
.PAR(xx, ..xx).
The actual name of the sub-routine must be defined in the PGM.FILE record in
the field BATCH.PROCESS prefixed by a @. This is invoked from RGS....
program generated.It uses the arguments - Par1, Parn where Parn may be any
number of parameters (at least one) as per the definition in PGM.FILE.
All details required in the subroutine from the repgen must be passed into the
subroutine as separate arguments. A single value may be returned.
1.4.5 PRINTER.ID
Allows definition of a command (or routine) which can be used to create a file of
printed output. This means that whenever GLOBUS output is directed to this
printer id the command will be invoked.
1.4.5.1 COMMAND
Any UniVerse command or subroutine may be specified here. Usually a UNIX cat
command will be used to build a file.
Format: Command
Command may be any executable command from Universe. It is invoked from
EXECUTE.COMMAND.
The routine is driven from F.HOLD.CONTROL, and will be able to pass the id in
the command line. This can then be accessed within any required routine using
the system variable @SENTENCE.
For example, the command specified could be:
LOCAL.PRINT.LOAD &HOLD.CONTROL>@ID&
The routine would then have to check @SENTENCE[ ,2,1] in order to extract
the ID.
Page 20 of 25
1.5
DELIVERY SYSTEM
1.5.1 Introduction
The GLOBUS delivery system provides the ability for user defined routines for
mapping messages, control of disposition, processing SWIFT interfaces, and for
formatting inward and outward Swift messages. The Delivery system has been
further opened up to enable users to define their own formatting rules for
messages and to write interface routines, using the Generic Delivery Interface.
1.5.2 DE.FORMAT.SWIFT
The DE.FORMAT.SWIFT application allows a subroutine to be called for a
particular Swift Field when processing incoming Swift messages
1.5.3 DE.WORDS
This application allows a user routine to be defined for a given language to allow
translation of numbers to words.
1.5.4 DE.DISP.CONTROL
A user-defined routine may be called to provide enhanced selection for
disposition control.
1.5.5 DE.MAPPING
The DE.MAPPING application allows a user subroutine to modify the information
passed to APPLICATION.HANDOFF by the calling application and hence to map
additional data which is not normally available for the message type.
1.5.6 DE.CARRIER
The delivery carrier file, DE.CARRIER, contains details of all the carriers
available in Delivery. To enable a carrier, it must be specified on the Delivery
Parameter file, DE.PARM.
The ID of this file is the name of the carrier, as used in DE.PRODUCT. Each
record contains the address type to be used for the carrier (i.e. when accessing
DE.ADDRESS), the formatting rules (DE.FORMAT.carrier) and the carrier
module (e.g. DE.O.CC.SWIFT). If the carrier module is GENERIC, i.e. the
messages are handled by the generic program DE.CC.GENERIC, interface must
be specified. The interface must reference a record on DE.INTERFACE, which
contains details of the protocol for all generic interfaces (non-generic interface
details are stored on the parameter file, DE.PARM).
When the record is authorised, formatting and carrier files are created if they do
not already exist. These files are F.DE.O.MSG.format-module and
F.DE.O.PRI.format-module for the formatting files and F.DE.O.MSG.interface and
F.DE.I.MSG.interface for the interface files.
1.5.7 DE.INTERFACE
Page 21 of 25

This file contains details of the protocols for all interfaces which use the Generic
Delivery Interface. The protocols for interfaces written prior to the introduction of
the Generic Delivery Interface are either stored on DE.PARM or are hard-coded
in the program. Sequence numbers for existing interfaces are stored on
F.LOCKING.
The id of the file is the interface as defined in the interface field on DE.CARRIER.
There is little validation of the fields on DE.INTERFACE. This is to allow for
maximum flexibility when new interfaces are written. Each field can be used to
control how the interface is defined and used and more information can be found
in the Helptext.
1.5.8 DE.MESSAGE
A routine can be defined to process inward messages to generate Funds
Transfers using the OFS module.
1.5.9 FD.ACTIVITY
The Fiduciary application allows subroutines to be called to modify the contents
of data passed to delivery from the application.
1.5.10 MG.ACTIVITY
The mortgage application allows subroutines to be called to modify the contents
of data passed to delivery from the application.
1.6
INTERFACES - LOCAL CLEARING
1.6.1 Introduction
GLOBUS provides options for allowing the required additional functionality to be
added to the Funds Transfer module in order to allow local clearing transactions
to be entered according to the local rules. This functionality is provided by the
parameter file FT.BC.PARAMETER for the local clearing transaction types, BC,
BI and BD. The parameter allows subroutines to be added to perform specific
local validation, and update of cross-reference files and production of
additional/new delivery messages.
A further option allows a sub-routine to be invoked from the delivery processing,
which can allow diversion of messages with different carriers into the local
clearing system according to the coded rules.
Page 22 of 25
1.6.2 FT.BC.PARAMETER
This application allows customisation of existing field level validation for the BC
Funds Transaction type. Additionally subroutines may be defined to perform
specific local validation within the FT module in the following fields:
FT.VALIDATION.RTN
FT.DELIVERY.RTN
STO.VALIDATION.RTN
BULK.STO.VALID.RTN
Additionally the ability to define subroutines called from the CUSTOMER and
ACCOUNT applications is provided in the fields:
ACCOUNT.UPD.RTN
CUSTOMER.UPD.RTN
A subroutine to allow diversion of messages into the local clearing system within
the delivery system may be defined in:
DIVERSION.RTN
1.6.3 FT.TAPE.PARAMS
The FT.TAPE.PARAMS application manages import and export of data for the
local clearing system(s) installed. Data is typically downloaded or uploaded onto
tapes, or directly to a specified file. Subroutines and commands may be defined
for each type of interface which are used for:
LOAD.CMD
LOAD.ROUTINE
UPDATE.ROUTINE
CREATE.CMD
CREATE.ROUTINE
GENERATE.ROUTINE
ENQ.PURGE.ROUTINE
1.6.4 AC.ENTRY.PARAM
The AC.ENTRY.PARAM application controls the Generic Accounting Interface. It
contains booking details of entries supplied in an external ASCII file, and the
layout of the file. The standard routine AC.INWARD.FILE should be used as the
UPDATE routine in FT.TAPES to run the generic interface. Additional validation is
possible by calling user routines.
Page 23 of 25
1.7
LOCAL STATUTORY REPORTING
1.7.1 Introduction
GLOBUS allows subroutines to be called at input time for the applications
FUNDS.TRANSFER. DATA.CAPTURE, TELLER and DRAWINGS, which can
validate and default local reference values used in local reporting. Typically an
activity code will be allocated according to the type of contract entered.
1.7.2 BANK.RETURN.PARAMS
This application allows definition of subroutines to be called from the TELLER,
FUNDS.TRANSFER, DATA.CAPTURE and DRAWINGS applications at input
time to allow defaulting and validation of local reference items. The record
applicable to the company is defined in LOCAL.PROCESS in the COMPANY
record.
1.8
TAKEOVER / INSTALLATION CUSTOMISATION
1.8.1 Introduction
In order to assist the takeover of existing systems when installing GLOBUS, the
system allows linkage of subroutines. Subroutines will usually be required to
perform processing which allows existing file structures to be mapped into the
appropriate GLOBUS data files.
1.8.2 ALT.ACCT.PARAMETER
The application ALT.ACCT.PARAMETER, allows definition of the details of the
account number structure in the existing system. The old account number is
stored in a cross-reference table linking it to the new GLOBUS account number,
called ALTERNATE.ACCOUNT.
1.8.3 EBS.AUTO.FUNCTION
The system allows a subroutine to be inserted when building the input buffer
when contents need to be calculated, and when maintaining totals for the records
processed.
1.8.4 TAKEOVER.MAPPING
Subroutines may be defined in TAKEOVER.MAPPING to format data into the
expected GLOBUS format from the source files, and to manipulate data
according to specific rules. For example a cross-reference table may need to be
maintained in order to build the correct link between GLOBUS records.
Page 24 of 25
1.9
LIMITS
1.9.1 Introduction
In order to allow complex calculations of risk factors to be applied to limit
products or sub-products, the LIMIT.REFERENCE application allows definition of
a subroutine, which may be invoked. The subroutine will return the amount of a
given transaction to be recorded in the limits system.
1.10 COMPANY CUSTOMISATION
1.10.1 Introduction
In order to allow for different account number structures and checkdigit
calculations, the checkdigit type may be defined as a user routine, which will
perform the desired formatting and checkdigit validation. This routine should also
return the next available id if called from the ACCOUNT application with F3 or F2
entered at awaiting id. The routine is specified in the COMPANY record.
Page 25 of 25

Version Routines and API

Uploaded by

Copyright:

Available Formats

Version Routines and API

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Version Routines and API

Uploaded by

Copyright:

Available Formats

What customization options are available in GLOBUS applications?

What customization options are available in GLOBUS applications?

How can user defined subroutines be used to customize applications?

How can user defined subroutines be used to customize applications?

T24 Technical Training

Application Program Interfaces

T24 Technical Training

Application Program Interfaces

T24 Technical Training

The following steps must be followed:

User-defined subroutine must be defined in PGM.FILE as a type S application.

Figure 1.1 PGM.FILE For V.INDUSTRY.NAME

Figure 1.2 VERSION Automatic defaulting definition

Application Program Interfaces

T24 Technical Training

VALIDATION.RTN (Field 40.1)

This field, together with VALIDATION.FLD, allows definition of subroutines to be

Contains the contents of specified VALIDATION.FLD.

Application Program Interfaces

T24 Technical Training

In the version the following are specified :

Version -Validation Routine

AUTH.ROUTINE (Field 45.1)

The subroutine may be executed at the authorization stage of transaction

Application Program Interfaces

T24 Technical Training

Version Authorization routine

Application Program Interfaces

T24 Technical Training

INPUT ROUTINE (Field 44.1)

A subroutine may be executed at the unauthorized stage of transaction

Figure 1.5 SMS control for version

Specifies the Application used to access records belonging

Specifies a particular Version which may be used to access

Specifies the functions that may be used to access records

Application Program Interfaces

T24 Technical Training

Specifies against which field the condition is to be met. Ex

DATA.COMPARISON Specifies the type of comparison to be made between the

Specifies the value, or start of a range of values, with which

Specifies the end of a range of values with which the

Definition of Subroutines to be used in applications

1.2.4.1 PROGRAM (ID)

Application Program Interfaces

T24 Technical Training

The PGM.FILE record for SB.LIST.LOCKS is as follows:

The result of execution of SB.LIST.LOCKS subroutine at GLOBUS Action prompt

Application Program Interfaces

T24 Technical Training

Application Program Interfaces

T24 Technical Training

SYSTEM MANAGEMENT CUSTOMISATION

REPORTING / ENQUIRY CUSTOMISATION

Application Program Interfaces

T24 Technical Training

Application Program Interfaces

T24 Technical Training

EXTERNAL LINK TO ENQUIRIES