DELIVERY

Objectives

 To understand the outward delivery system in Globus

 To understand the delivery carriers
 To understand the important files in Globus that control the delivery system in Globus
 To understand ways and means to control the sending/printing of delivery advices

1.1 Introduction

Most on-line transactions within GLOBUS will send messages. For example, when a
LD transaction is entered and approved it will usually require the sending of an advice to a particular
address containing the details regarding the transaction. In addition, some overnight processing, such
as the processing of standing orders, will also require the sending of advises. This process of sending
advises is achieved through a module in GLOBUS called ‘DELIVERY’.

2.1 Delivery Carriers:

DELIVERY CARRIERS

SWIFT TELEX PRINT

Figure 1.1 Delivery Carriers

A delivery advice could be sent and received in three different ways.

2.1.1 Swift (Society for Worldwide Interbank Financial Transactions) carrier

The SWIFT carrier is used to send and receive SWIFT messages. SWIFT is the
standard that is followed by banks all over the world to communicated with one another. The header
and trailer required by SWIFT are generated automatically as they are standard. The maximum size
of a SWIFT message is 2000 characters (There is an exception to this rule which we will learn as we
proceed further).

2.1.2 Print Carrier

Print carrier is used to print the delivery advises. It is possible to define different
formats so that a document can be printed in different versions or languages as required by particular
customers.

2.1.3 Telex

Not widely used anymore.

3.1 The Delivery Subsystem In Globus

Delivery messages can be of two types namely inward and outward. Inward delivery
messages are the ones that we receive from external sources and the external delivery messages are
the advices that go out of our delivery subsystem to other sources. This material will help you
understand the outward delivery system only.

Before we understand the delivery subsystem, let us first understand the concept of
phantoms. In simple terms, phantoms are nothing but background processes that remain active until
EOD (End Of Day) is initiated. Most of the processes in the delivery subsystem are run as phantom
jobs.

Temenos Training Publications 60

 Advices that go out of our delivery subsystem pass through a number of stages
before they reach their destination. If you had noticed, when you commit transactions in LD, a
message stating ‘SENDING ADVICE 320.LD.1 or 900.LD.1’ etc would get generated. This message
denotes that a delivery advice is getting generated.

REFERENCE………………… D20000811-000383957000.1
-----------------------------------------------------------------------
***********************************************************************
PAGE 1 PAGE 1 PAGE 1 PAGE 1 PAGE 1
***********************************************************************

DATE : 22 FEB 2000 A.B.N. Amro

Foppingaddref 234
CONTRACT : LD/00053/00200 1102 BS Amsterdam,
Holland

CUSTOMER : 100069
-----------------------------------------------------------------------
DEPOSIT CONFIRMATION
-----------------------------------------------------------------------

WE CONFIRM YOUR DEPOSIT WITH US AS FOLLOWS:

SETTLEMENT OF PRINCIPAL & INTEREST

==================================
WE WILL CREDIT YOUR ACCOUNT 18651

IF YOU SHOULD HAVE ANY QUERIES REGARDING THE ABOVE DETAILS KINDLY CONTACT US AS SOON AS
POSSIBLE QUOTING THE CONTRACT NUMBER IN FULL.

THIS ADVICE BEARS NO SIGNATURE

------------------------------

RECEIPT OF PRINCIPAL VALUE: 01 JAN 1999

WE WILL DEBIT YOUR ACCOUNT 18651

***********************************************************************
Figure 2.1 Sample delivery advice generated when a deposit is made using the LD application.

As you can notice, this advice contains only necessary information and not all the
information that is part of the original transaction. As all the data cannot be dumped onto the advice,
there arises the necessity to specify the information that needs to be a part of an advice.

When a transaction, that requires the sending of a message, is authorized, the

Delivery process "APPLICATION.HANDOFF" is invoked. This passes all the details of the message
to a file called ‘DE.O.HANDOFF”, whilst passing back a unique identifier to the application, the
Delivery message id. This DE.O.HANDOFF is a dimensioned array and contains 10 dynamic arrays
within it. The first 7 arrays are used by the system to populate values. The last 3 arrays can be used
by users to populate user-defined values (As a convention we use the 9 th array to fill in user defined
data).

D20000809000214655900

Sample Deliver Reference Id (Field Number 153.1 in LD application) Passed to the

LD application by APPLICATION.HANDOFF process when a deposit is made

"X" "D" - message is to be delivered (outward message) or

"R" - message has been received (inward message)
"YYYYMMDD -" the date
"NNNNN" - the system user number of the inputter
"SSSSSSS" - the time in seconds since midnight
"QQ" - the sequence number of transactions within a second

Temenos Training Publications 61

 In order to pickup the necessary data from the handoff file and display it in the advice,
we would require variables/fields. The various fields that are to hold the data picked up from handoff
file have to be defined in a file called DE.MESSAGE.

Once the variables have been created, the necessity now arises to link the fields to
the values in the handoff file. This mapping is achieved by using file called DE.MAPPING.

Now that the data is ready, the only thing pending is the formatting of data, or the
advice layout. All formatting for PRINT messages are done in a file called DE.FORMAT.PRINT. For
SWIFT messages formatting is done in a file called DE.FORMAT.SWIFT.

Once the advice is formatted, it has to go to the specific destination through the
specified carrier. Now arises the need for us to understand the use of the tables

DE.PRODUCT
DE.ADDRESS

The DE.ADDRESS table is used to look up to find out to whom the advice has to
reach (address).

It is in the DE.PRODUCT table that the Status (Normal, Hold or Delete) and Priority
(Normal, Priority or Urgent) for a particular message is checked for. It also specifies for each
Carrier/Delivery Address, which version of the format should be used, and how many copies should
be made of that particular advice. We will learn more about these files as we proceed further.

The main processes within Delivery (i.e.) mapping, formatting and carrier control
processes are run as phantom jobs. These phantoms can be started or closed using the DE.MENU
utility (Type ? DE.MENU at the command line). Alternatively, DE.PHANTOM can be used to start and
shutdown the phantoms.

Temenos Training Publications 62

The Working Of The Delivery Subsystem

3.2 Flow of a delivery advice :

Application

Transaction
Pass
Back
delivery
reference
id
Application Handoff

Delivery System (DE.O.HANDOFF)

Read
Unmapped Queue DE.O.MAP.MESSAGES

DE.MAPPING

Write on to DE.O.HEADER

Send
Mapped Queue Create header and detail for the advice

Select a message
Unformatted Queue DE.O.SELECT.NEXT.MESSAGE
Check for priority
Read

DE.PRODUCT
Check to see
1)To whom the advice has to be sent
2)Number of copies
3)The carrier to be user
DE.ADDRESS
Check to see the address
1)To whom the advice has to be sent
2)Number of copies
3)The carrier to be user
DE.FORMAT.XXXXXX
Check to see how the advice has to be sent
Formatted Queue

Carrier

Print Swift Telex

Figure 3.1 Flow Of A Delivery Advice

Temenos Training Publications 63

 The main processes within Delivery, i.e. mapping, formatting and the carrier control
processes, are run as phantom jobs, normally running continuously throughout the day and during the
end of day processing, only being stopped for the backups to be taken.

The mapping process DE.O.MAP.MESSAGES examines the Unmapped queue in

chronological order for any messages to be mapped. From the raw data in the Unmapped file, a
Header record and a Message Detail record are created, using the mapping rules described on the
Mapping table

DE.MAPPING. The message is then placed on the Unformatted queue.

The formatting process DE.O.SELECT.NEXT.MESSAGE examines the Unformatted

queue, in chronological order within priority for any messages to be formatted. The appropriate
Product record DE.PRODUCT is read to determine to whom the message should be sent, how many
copies and which carrier should be used. The carrier, as specified on the product table, is used to
access the carrier table, DE.CARRIER. This file contains the carrier to be used for formatting, address
table look-ups, the carrier module and the interface to be used. E.g. The product table specifies a
carrier of TELEX. The carrier record specifies for telex that “TELEX” should be used for the address
record look-ups, “SWIFT” should be used for formatting, the “GENERIC” carrier control program
should be used and the interface should be “TELEXBOX”. The Address table DE.ADDRESS is
accessed to determine the address to which the message should be sent, e.g. the print address, the
SWIFT id, the Telex number, etc. The appropriate format table (e.g. DE.FORMAT.PRINT,
DE.FORMAT.SWIFT) is read to determine how the message should be formatted, producing a
formatted print message, formatted SWIFT message, etc. The formatted message is then placed on
the appropriate Formatted queue e.g. Formatted SWIFT, Formatted Print, etc.

4.1 Tables And Programs That Form An Integral Part Of The Delivery Subsystem

4.1.1 DE.MESSAGE

It is the DE.MESSAGE table that we define the fields that hold the data extracted
from the DE.O.HANDOFF record. The attributes of the field such as the field name, length of the
field, single value or a multi-value, mandatory or optional etc are specified here. Every message type
has a record in this table. Hence, if you want to modify the field details of a field that is part of a 320
message type, you need to open a record with id 320 in the DE.MESSAGE table.

Figure 4.1 DE.MESSAGE Record

Temenos Training Publications 64

4.1.2 DE.MAPPING

It is the DE.MAPPING table that allows us to map the fields defined in the
DE.MESSAGE table with the various values in the DE.O.HANDOFF record.

Field position in DE.O.HANDOFF

Field name defined in DE.MESAGE

Figure 5.1 DE.MAPPING Record

Sample (A part) record of DE.MAPPING table with ID “320.LD.1”. The id of a record in DE.MAPPING
is made up of

MessageType.ApplicationName.Format
Field Number 1 3 26.1
(As in DE.O.HEADER)

Note

See the contents of DE.O.HANDOFF using SEE.HANDOFF followed by the

Delivery Refernece Id from the database prompt.

4.1.3 DE.O.HEADER

To view the status of a message, the message has to be mapped as well as

formatted. Once the message has been mapped, basic detail message record as defined in Message
is created but its contents cannot be inspected until they have been formatted. Another record exists
containing the header fields that were defined in Mapping. This record can be viewed using the
DE.O.HEADER (Outward Header). It is in this table that the message type, application format
(Format to be used when messages are generated by this application. This is hard coded in the
delivery system), name of the application that generated the message, number of copies to be sent,
language to be used, priority of the message are specified.

View the contents of DE.O.HEADER with the delivery reference id.

Temenos Training Publications 65

 Figure 6.1 DE.O.HEADER Record

It is this file that shows the status of the messages. As we are aware, for a message
to reach the destination through the delivery subsystem, it has to be mapped and formatted. Problems
could arise in any of the stages. DE.O.HEADER table contains a field called ‘Disposition’ which shows
the status of the message. Following table contains a list of message stages and their respective
dispositions.

Message Status Queue Disposition Error Description

Problem In Mapping Repair Queue Repair *ERROR.CODE
Successfully Mapped Unformatted
Problem In Formatting Unformatted Repair *MSG.ERR.CDE
Queue
Successfully Formatted Formatted
Successfully Printed ACK
 Will hold the error description

In case a problem arises during the formatting stage and the disposition is set to
repair, one can check the error description in MSG.ERR.CODE/ERROR.CODE, make the necessary
changes and ‘RESUBMIT’ to the delivery subsystem for processing. To resubmit the message,
change the (last multi-value of) disposition form ‘REPAIR’ to ‘RESUBMIT’ and commit the record.

Temenos Training Publications 66

4.1.4 DE.PRODUCT

Input an LD transaction that will deposit 100 GBP onto the account of ABN Amro
(Customer Number 100069) and authorize the transaction. Notice the message “Sending advice
320.LD.1010”.Incase you input an FT transaction with transaction type as ‘AC’ you would find a
message ‘Sending advice 900. …..’ etc. These 900,320 etc are product types that have been hard
coded in GLOBUS. There are number of existing message types in GLOBUS namely
900,320,910,950 etc. Using the DE.PRODUCT file, GLOBUS gives us the flexibility to create
restrictions that would enable us to send advices to a specific

 Company–Customer–MessageType–Application
GB0010001.C-100069.320.LD1.1
 Company–Account–MessageType–Application
GB0010001.A-123456.320.LD1.1
 Company-Customer-MessageType-All Applications
GB0010001.C-100069.320.ALL
 Company-Customer-All Message Types-All Applications
GB0010001.C-100069.ALL
 Company-All Customers-All Message Types-All Applications
GB0010001.ALL.ALL

Figure 7.1 Sample DE.PRODUCT record with ID GB0010001.100.ALL

Temenos Training Publications 67

4.1.5 DE.ADDRESS

It is the DE.ADDRESS file contains the names and address of a bank's customers
and also of each company within the banking organisation. When a customer record is authorized, a
record in the DE.ADDRESS file gets created with the carrier PRINT and with the address specified in
the customer record.

The basic postal address of each Customer is stored in the following format

Print address

ID = Company.C-Customer.PRINT.1
Figure 8.1 Sample record from DE.ADDRESS table with ID “GB0010001.C-100069.PRINT.1”

Fields 6.1 to 10.1 are used to specify customer’s addresses and are used by advices
that have to go through the print carrier.Field number 1 is used to specify the swift addresses and is
used by advices that go through the swift carrier.

Swift address

Figure 9.1 Sample DE.ADDRESS record which contains a swift address

Temenos Training Publications 68

4.1.6 DE.CARRIER

If you notice in the above picture, the DE.PRODUCT tables requests for a carrier
address number (Field Number 3.1 CARRIER.ADDR.NO). This is nothing but the id a corresponding
record in DE.CARRIER table. DE.PRODUCT tables allows us to specify the carrier that a particular
type of message has to take, apart from other attributes like the language (Field Number 4.1), number
of copies to be sent (Field Number 6.1) etc. The attributes of the carrier to be used are specified in a
table called DE.CARRIER.

Sample DE.CARRIER record with ID “PRINT”

Figure 8.1 DE.CARRIER Record

Figure 10.1 DE.CARRIER Record With Id PRINT

Field 2 ADDRESS Specifies the type of address to be used for this carrier. This is
usually the same as the record id.

Field 3 FORMAT.MODULE Specifies the formatting module to be used. If a value PRINT is

entered here, a formatting module DE.FORMAT.PRINT will be
checked for the formatting rules to be followed while formatting a
particular message.

Field 4 CARRIER.MODULE Specifies the name of the carrier module. For most of the existing
modules this will be the same as the formatting module. Default is ‘GENERIC’.

4.1.7 DE.FORMAT.PRINT

The DE.FORMAT.PRINT table defines a format for a printed document. It is possible

to define different formats so that a document can be printed in different versions or languages as
required by particular customers. It is in this table that we design the layout of the advice, specify
headings(if any), the indentation, the position of fields etc. This table also allows us to perform some
calculations (Field – CONVERSION). Field numbers). The id records in the file are made up of

MessageType.ApplicationFormat.NumberOfCopies.LanguageCode
Field Number: 1 2 26.1 16
(As in DE.O.HEADER file)

These details are picked up from the DE.O.HEADER file.

Temenos Training Publications 69

 Figure 11.1 DE.FORMAT.PRINT Record

4.1.8 QS

QS is the abbreviation of the program DE.MM.DISPLAY. When executed, this program

displays the various queues and on choosing the queue, shows the records in that specific queue.

Figure 12.1 Output Of QS

Temenos Training Publications 70

4.1.9 DE.MENU

DE.MENU is the menu that is used to check the status of phantoms, start and stop phantoms.
Type, ?DE.MENU at the application prompt to access the menu options.

Figure 13.1 Output Of DE.MENU

4.1.10 DE.MM.PRINT.MSG

This is used to print the contents of a Formatted message, or display them on the
screen.

Type DE.MM.PRINT.MSG at the command line

System will prompt

Do you wish to display or print the messages?

Enter D (Display), or P (Print) or <RETURN> to end.

Type D to view the message on the screen or type P to send the advice to the printer

System will prompt for the message key. Type the Delivery Reference Number.

4.1.11 DE.PARM

Contains the parameters that allow the operator to shut down the carrier control modules, and
the inward and outward formatting modules. Contains only one record with the id SYSTEM.STATUS.
Shut-down can be:

 Urgent (after the message currently being processed.)

 Normal (when all queues have been processed.)

Temenos Training Publications 71

 Status ‘C’ denotes Closed and ‘A’ denotes
Active

Figure 14.1 The SYSTEM.STATUS Record Of The DE.PARM File

Note
To ensure that an advice gets generated, handoff produced but the advice does not get printed
In File DE.PARM
Field Number 14.1 PRINT BYPASS
Value DE.MESSAGE Id
To ensure that a delivery advice does not get generated at all
In File DE.PRODUCT
Field Number 1 MESSAGE STATUS
Value DELETE
(Please note that if a value DELETE is specified like above, even the HANDOFF will not get
generated)

Temenos Training Publications 72

Summary

 The delivery system in Globus is used to send and receive advices

 Advices can be sent either to a customer or to another bank
 Print, Swift and Telex are the 3 carriers used by the delivery system
 DE.MESSAGE – Used to define the various message types
 DE.MAPPING – Used to link the fields defined in DE.MESSAGE to positions in the
APPLICATION.HANDOFF
 DE.O.MAP.MESSAGES is the mapping phantom
 DE.O.SELECT.NEXT.MESSAGE is the formatting phantom
 DE.FORMAT.PRINT – Used to format print advices
 DE.O.HEADER – Contains the status of a delivery advice
 DE.MM.PRINT.MSG – Mainline program that is used to view/print delivery advices online
 DE.PRODUCT – Used to specify restrictions on which advice needs to pick which carrier
 DE.ADDRESS – Contains the SWIFT address or the Customer address to which the delivery
advice needs to be sent to
 Use QS to view in which queue the delivery advice is in
 Use DE.MENU to start and stop delivery phantoms
 DE.PARM is the main parameter file of Delivery.

Additional Information

DE.INTERFACE

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. There is little validation of the fields on
DE.INTERFACE. This is to allow for maximum flexibility when new interfaces are written. The id
of the file is the interface as defined in the interface field on DE.CARRIER.

DE.DISP.CONTROL

In addition to all the conditions available in the Delivery Product file this table can hold
a variety of special controls. For example, it may specify:

 All messages for Hong Kong branch must be held until midnight.

 All messages with amounts greater than two million dollars are urgent and require immediate
confirmation.

 All messages for a particular carrier must be rerouted. (In this case the Alternate Carrier List is
looked up to find the new carrier.)

 Print a copy of all messages which have a Message Type of 100 and an amount of more than
USD 500000 or GBP 200000.

Temenos Training Publications 73