Professional Documents
Culture Documents
SERVICE
OFS.MESSAGE.SERVICE:
OFS.MESSAGE.SERVICE is a standard T24 service with its own workload profile. Ensure that the
OFS.MESSAGE.SERVICE is started by committing the TSA.SERVICE record.
OFS message should get written on to a file named F.OFS.MESSAGE.QUEUE. This is the IN queue from where
the service OFS.MESSAGE.SERVICE picks up the data and processes.
Once the message is processed, the response is written on to an out queue named F.OFS.RESPONSE.QUEUE.
The service OFS.MESSAGE.SERVICE is a multi threaded service and needs to be started like any other service. It
also requires the tSM to be up and running. The SERVICE.CONTROL field of OFS.MESSAGE.SERVICE record
in TSA.SERVICE application can be set to AUTO, so that whenever the new messages comes it will process it and
stop the service till next message comes.
1) PGM.FILE
2) TSA.SERVICE
3) BATCH
4) WORKLOAD PROFILE
PGM.FILE:
TSA.SERVICE:
BATCH ENTRY:
Sample workload profile:
An API called OFS.POST.MESSAGE has been introduced to facilitate inter-application OFS calls.
OFS.POST.MESSAGE
Syntax:
Explanation:
• Application name, record id and field information's will be passed through the first argument
Y.OFS.MESSAGE
• OPTIONS is the fourth argument, which contains the "USER ID" need to be used to process that transaction.
Here, if we give the user id in the fourth argument then that user will be taken for processing.
If the USER part is left blank then the USER specified in the USER field of TSA.SERVICE record -
OFS.MESSAGE.SERVICE will be taken in account for processing the transactions and from the
OFS.SOURCE.
Note: From the information received, we understand that the requirement is to process the OFS requests from each
bank should be processed separately.
Using this fourth argument you can set up the specific user to process the request from each bank and you can also
set up the specific OFS.SOURCE for each bank. Hence with help of the fourth argument you achieve the
requirement.
Step1:
SUBROUTINE POST.RTN
$INSERT I_COMMON
$INSERT I_EQUATE
Y.SRC = “GLOBUS”
OPTIONS = ‘’
CALL OFS.POST.MESSAGE(Y.STR,MSG.ID,Y.SRC,OPTIONS)
CALL JOURNAL.UPDATE(“”)
RETURN
END
If the local routine is run as a mainline then the JOURNAL.UPDATE should be invoked.
Whereas it is invoked from any version routine or any service then JOURNAL.UPDATE shouldn’t be invoked.
Step 2:
Setup the OFS.SOURCE record
Step 3:
Step 4:
After running the local routine post the OFS request into the F.OFS.MESSAGE.QUEUE.
Ex:
Step 6:
tSA 2
_OFS.MESSAGE.SERVICE_OFS.MESSAGE.SERVICE_2_09 NOV
2012_12:07:44_Calling..OFS.MESSAGE.SERVICE.SELECT
_OFS.MESSAGE.SERVICE_OFS.MESSAGE.SERVICE_2_09 NOV
2012_12:08:03_Complete_43659_43683_00:00:24_1
Agent stopped
Step 7:
163850000142053.00.1
001 1
002 DESCRIPTION:1:1=SDFG,SHORT.NAME:1:1=SDFG,RECORD.STATUS:1:1=INAU,CURR.NO:1:
1=1,INPUTTER:1:1=42_INPUTTER__OFS_GLOBUS,DATE.TIME:1:1=1211090655,CO.CODE:
1:1=GB0010001,DEPT.CODE:1:1=1
003 1003
A second service, OFS.RESPONSE.QUEUE, purges the OFS.RESPONSE.QUEUE file according to the minutes
entered into the ATTRIBUTE.VALUE field on the TSA.SERVICE record. If a record is older than the time in
ATTRIBUTE.VALUE,it will be deleted.
• The ATTRIBUTE.TYPE and ATTRIBUTE.VALUE fields are not validated as they are free form fields to
be used by TSA.SERVICE records to contain any value that a service may require.
• For OFS.RESPONSE.QUEUE, the duration (in minutes) is entered into the ATTRIBUTE.VALUE field. If
a numeric value is not entered into this field, records will not be purged from the OFS.RESPONSE.QUEUE
file when this service is run.
This service has a workload profile similar to that of OFS.MESSAGE.SERVICE. A sample profile is shown below
Fig 29: TSA.WORKLOAD.PROFILE entry for OFS.RESPONSE.QUEUE