T24 Essentials Key points

Units of Products:
- T24 products catalogued in EB.PRODUCT
- T24 products components are Applications, Versions, Enquiries & services
- PGM.FILE -> PROGRAM File -> Catalogue for all Applications & sub-routines/jobs in T24
- Any Command executed in command line will have an entry in PGM.FILE
- ID of PGM.FILE is -> Application name
- T24 Application-> Records the data entered and stores it in an associated file eg. CUSTOMER,
TELLER
- Services -> programs run as background without user intervention -> Helps in automation ->
Catalogued in TSA.SERVICE application
- Enquiry – is a query to fetch data from DB and display the results in a user defined format ->
Catalogued in ENQUIRY application -> Launched as ENQUIRY <enquiry name>
- Versions- Customized screen that displays required fields from the application -> Catalogued in
VERSION application -> ID is APPLICATION,VERSION.NAME
=====================================================================================
T24 Application and Structure Files:
- Up to 4 tables can be associated with an application (not always only one table, i.e. minimum
1 to maximum 4 tables can be available for an application)
- In T24, Users created as Inputter (with only entering privs) & Authorizer (with approve priv)
- Inputter can only input the data and validate but cannot approve the created record. On
approving “EB.RTN.SAME.NAME.AUTHORISER/INPUTTER” error will get displayed
- Privs for a user can be given as
o A – Authorizer
o 2 – 2nd level authorizer
o B - Not used
o C – Copy
o D – Delete a record (only if the record is in unauthorized state)
o E – List the Exceptions (only unauthorized records will get displayed)
o H – History Restore (only LIVE records can be restored)
o I – Input the record
o L – List the Live/ authorized records only
o P – Print the record
o R – Reverse the record (which is no longer used (only authorized record can be
reversed))
o S – See (View only)
o V - Verify function (used in some applications only- while doing RECORD.LOCK)
o Q – Audit
- On authorizing a record two records will be stored
o Live record – Current version of the record (once record moved from unauthorized to
authorized state)
o History record – older version of the record
- Delete history file captures record which is deleted in unauthorized state which is later used for
audit purpose
- Audit fields of an application -> Non-editable -> auto stamped fields which is present in all
applications attached to every record (Auditor name, auditor date & time, auditor code)

1
 o RECORD.STATUS -> Holds the status of the record (INAU, IHLD, INA2, INAO, RNAU,
RNA2, RNAO, HNAU, REVE) -> For a live record status is blank/NULL
o CURR.NO – Holds no of times the record got edited (<user id>;1)
- Naming Conventions -> Unauthorized record (Application name $NAU), Authorized/ live record
(Application name), History record (Application name $HIS), Deleted record (Application name
$DEL)
- Status of the records -> Unauthorized record (INAU, IHLD, INA2, INAO, RNAU, RNA2, RNAO,
HNAU), Authorized records (BLANK/ REVE – after moving to history file), Deleted records (same
as unauthorized)
- When a live record is amended, it is available both in LIVE (without new changes) & $NAU
(with modified fields awaiting for approval). Once authorized the record which was in LIVE
moves to $HIS and which was in $NAU moves to LIVE
- FILE.CONTROL – Holds files associated with application (at database level) -> ID is Application
name
- STANDARD.SELECTION – DICT (dictionary) file for every application -> holds the information
about the fields in an application -> ID is Application name
=====================================================================================
T24 Navigation & Environment:
- To create a record -> Type <Application name> I F3
- Once created, it moves to INAU state then authorizer commit the record which is moved
automatically to LIVE state
- Once authorized, the record can reversed and cannot be deleted
- In a record, + -> Expands the multi value, > -> Sub value expansion, I -> Context enquiry
- Record cannot be committed with errors
- With overrides (warning msg and can be customized based on channels, amounts, currencies,
type of transactions, etc.) a record can be committed (Overrides can be converted to errors)
- Override field is present in all applications -> it’s a multi value field -> No input field
- USER application – holds the profile of the bank employee
- A branch in T24 called as COMPANY – Catalogued in COMPANY application – ID is Company
code – T24 offers multi branch solution i.e. one installation of T24 can support multiple
branches
- File sharing by companies
o CUSTOMER & COLLATERAL -> Customer (CUS) -> May /may not share ->
FBNK.CUSTOMER
o ACCOUNT & FOREX -> Financial (FIN) -> Always not shared -> FBNK.ACCOUNT
o DATES & CURRENCY -> Installation file (INT) -> Always shared -> F.DATES -> SPF holds
these information which is shared across branches – Not configured and not specific to
branches
o Note: BNK is company mnemonic – Both CUS & FIN configurable & specific to branches
- Classification of applications can be done in FILE.CONTROL where we can mention it as CUS/
INT/ FIN (Open any application in FILE.CONTROL -> Check Classification field -> This field holds
file type)
- T24 maintains own Dates -> DATES holds the date as of T24 system date and not the system
date – ID is COMPANY.ID- > Automatically roll fwd. by COB -> Date information is at company
level -> Stores Current, previous & Next working day detail
- Value date holds the date on which the transaction get authorized

2
 - HOLIDAY – application to indicate the holidays and weekends -> drives the login behind
calculating dates (during COB, if holiday then next day in DATES changed) –ID is <Country Code
Region code> Year. Eg, GB 00 2017
=====================================================================================
Defining Users & Configuring Security:
- SMS Applications – Create User profile (USER), Create User Group (USER.SMS.GROUP), Set
Password Characteristics (SPF), Password Reset (PASSWORD.RESET), Log file to track all user
activities (PROTOCOL)
- USER application
o creates an internal bank user
o Sign on name and User id should be different
o Company code – Branch code
o Company Restr – ALL (to access all branches) / holds specific company code
o Application field – ALL.PG (access to all applications)
o Functions (setting up the privs for the user A, 2, B, C, D, E, H, I, L, P, Q, S, V
o Classification – File type (CUS, INT, FIN)
- USER.SMS.GROUP application
o User group created with set of privs which can be assigned to a particular user
o Create group in USER.SMS.GROUP (eg. Manager) – assign functions
o Create a user in USER application – in application field attach ID of above created group
(manager) as @manager
- SPF – System Parameter File
o Company specific settings done using COMPANY table
o System wide parameters of all companies in SPF (INT type file)
o ID – SYSTEM
- Password Characteristics – Used to reset passwd & Unlock the user profile (PASSWORD.RESET
application and ID is any alphanumeric)
o Passwd – no more than two repeat characters, minimum 6 to maximum 16
o First sign on – two times passwd will ask
o USER PW ATTEMPT – ID of User whose account is locked (on authorizing, T24 resets the
pwd & enables the profile at the same time)
o USER Reset – ID of User whose password need to be reset with new passwd mentioned
in the field User Pwd
- Logging facility – PROTOCOL (used to track the user activity)
o PROTOCOL L / ENQ %PROTOCOL –list the user to view the activity details
=====================================================================================
T24 Versions:
- Versions is a customized screen in T24 – ID is <Application name>,<Version name>
- Allows to default value in fields – Allows to hide non-mandatory fields – Catalogued in VERSION
Application – can be created for any application
- Fields -> Print only – to print the record, RECORDS.PER.PAGE – no of records to be displayed in a
page, FIELDS.PER.LINE – One /Multi –no of fields that to be displayed in a line, FIELD.NO – field
name as specified in the application for which the version is created
- To insert a blank line in between the fields means use ‘*’ as value in Field.no
- No input field -> user cannot provide any input
- No of auth -> No of Authorizers for the version
- No change field -> After authorization user cannot amend
- Autom field no - To set the value as default (Aut old content & Aut New content)

3
 - Mandatory field – to mention the field as mandatory
- Rekey field
o on authorizing, the system prompts the user to reenter the value (while authorizing, this
field is hidden and while committing prompt is displayed)
o No of retires in SPF, the user/authorizer allowed no of retries (Attempts)
o EB.REKEY.RETRIES, record the number of incorrect retries done by authorizer
o ID in EB.REKEY.RETRIES -> COMPANY*APPLICATION*RecordID
- Zero authorizer – applicable for ACCOUNT, CUSTOMER & FUNDS.TRANSFER applications alone –
Versions created with comma doesn’t need authorizer (Self authorizer) – created as
VERSION, <APPLICATION NAME>,text
- Tabbed version – Associated versions can be created as tabs in the same version by specifying
the created version in ‘Assoc Version field’ (both the versions should be created under same
application)
=====================================================================================
Local fields:
- Local fields are user defined fields / customized by user and can be used across any application
- LOCAL.TABLE application used to create local field and set the props & once created the new
field should be attached to application using LOCAL.REF.TABLE
- Once the local field attached to the application, it cannot be deleted
- Fields in the LOCAL.TABLE,
o SHORT.NAME – actual field name to be displayed
o Minimum Char – makes the field as mandatory
o Char Type – Type of data to be input
o Vetting table – possible list of multi values of the local field
o In LOCAL.REF.TABLE, ID of local table created is attached to the field LOCAL.TABLE.NO
o Sub Assoc Code – denotes whether the local field is multi value
▪ XX. – single Multi value field (like Yes /No)
▪ XX< - start of assoc. multi value set
▪ XX- - part of assoc. multi value set
▪ XX> - end of assoc. multi value set
o On authorizing the LOCAL.REF.TABLE record, a record in STANDARD.SELECTION is
created for the created Local Field
o Usr. Type in STANDARD.SELECTION is denoted as ‘I’ (descriptive) for local fields
o Usr Field no – LOCAL.REF<1,4> - denotes that for the application it is 4th local field
- Order of created local field cannot be changed once LOCAL.REF.TABLE authorized
=====================================================================================
T24 Enquiries
- Enquiries fetches data from the DB and result displays in user defined format – Catalogued in
ENQUIRY application
- System defined enquiries starts with % or - and theses cannot be amended
- ENQ = ENQUIRY.SELECT – ID is ENQUIRY <any text>
- Fixed selection enquiries, Dynamic selection enquiries (first fixed and then dynamic)
- File name field contains the application or table to queried
- Two fields important, Page size – no of lines per page 4,20-> 4 lines for header & 20 lines for
records to be displayed, Header – Enquiry header to be displayed (sub value)
- Field name – field to be displayed (eg. ID)
- Operation – field name as in STANDARD.SELECTION (eg. @ID)

4
 - Column – order in which fields displays, mandatory and cannot be blank for any field
otherwise the field will not be displayed
- Enquiry executed as ENQ <any text>
- Fixed selection criteria- Fixed Selection field used to specify the criteria based on the fixed
requirement like ‘NATIONALITY EQ US’. First this executed before dynamic selection. Multiple
fixed conditions can be given in Fixed Selection 2, 3, & so on (internally AND operand executes)
- Dynamic selection given using Selection Flds field (multi value set), specify the operand in Sel
Fld Oper field and if the field need to be set as mandatory means give ‘Y’ in Required Sel
- Rel Next field used to do condition based selection criteria dynamically
- Sorting – performed using Fixed sort field with the value as ‘MNEMONIC DSND’ need to
mention the name of the field to be sorted
- Favourites – EB.SELECTION.FAVOURITES application allows user to save the selection criteria in
enquiries as favourites
- User specific fav & System wide fav
- Set ATTRIBUTES in ENQUIRY to NO.ENQUIRY.FAVOURITE to disable the favourites
- User specific fav
o ID is ENQUIRY*USERID
o Add required selection criteria and name of you fav
o Available only for the user specified
- System wide fav
o ID is valid ENQUIRY name
o Available to all user in the T24 system who launches the same enquiry
- Drill down
o Process of linking one enquiry to two or more
o navigate from one enquiry to another
o Create two enquiries to process drill down- Parent(CUST.ENQ) and child
enquiry(ACCTENQ)
o We can link different applications using drill down
o After creating child enquiry, attach the record id to Parent enquiry in the field ‘Enquiry
name’
o Sel Crit field (@ID EQ CUST.NO, whereas ID is the field name mentioned in child enq and
CUST.NO is equivalent field in CUST.ENQ enq). Used to link the enquiry/version
o Label field contains the value on which the child enquiry get invoked (eg. CUST.NO 2,
whereas 2 is default no)
o GB Next Desc field – holds the link name to be displayed
o Execute Parent enquiry from the o/p we can drill down to Account enquiry i.e. child enq
- Context Based Workflow
o From an enquiry we can invoke a version
o In Parent enquiry follow the same process of creation as drill down but in Sel Crit field
the value should be given as CUSTOMER>CUST.NO and in the Version ‘Aut New content’
field should have the value as ‘CUSTOMER>@ID’ (@ID- actual equivalent field name in
the application
=====================================================================================
T24 Menus:
- Menus are used by users for easy navigation through the application
- Menu can be an application, enquiry, version or any other menu
- In T24 there are two applications used to create Menus

5
 o HELPTEXT.MENU – (Lowest level of grouping menus)can create individual menus (as
links) and also we can connect different menus under a single menu
o HELPTEXT.MAINMENU – (Highest level of grouping menus)can create a main menu for
the application

- Creation steps
o ID of HELPTEXT.MENU is any meaningful alpha numeral text (HELPTEXT.MENU CUST)
o Provide the field values as, Application – can be an application name/ Version/ Enquiry/
Menu, GB Descript – name of the menu
o Executed as ?<Id of HELPTEXT.MENU>
o HELPTEXT.MAINMENU – ID must be a number (HELPTEXT.MAINMENU 123)
o Fields to be filled are, GB Title – Main menu description, Id of Help Menu – created
individual menu name, GB Descript – name of the sub/individual menu
o Executed as ?123
- Created Menus can be attached to USER profile in the field INIT.APPLICATION (in User
application), in this field mention the created HELPTEXT.MAINMENU Id. The created menus
launched when user logs in T24
=====================================================================================
T24 Release Methodology:
- Initially T24 releases are called as GA (General Availability) releases (once in a year)
- After release if the client reports an issue, the fix will packed to an update and provided to the
client in Updates portal for download
- Bug fixes are given as Updates
- New functionality/ enhancements were release in new release
- Internally Project Builds were released (PByyyymm) – there may be one or more project builds
in a month, usually these builds not shipped to the clients
- After R13GA, T24 moved to frequent releases as AMR (Annual Maintenance Release) –monthly
releases (early bird release- yyyymm)
- T24 announces an AMR when desirable no of enhancements were added. AMR is not once in a
year, it may one or more
- Frequent releases to the client, if any bugs/ enhancement provided after a release then the
changes/ fixes would provide to the client in the next release
- Monthly release include 2 phases,
o Month1 – Design & Construction Phase of YYYYMM release, Enhancements code, bug
fixes and unit testing completed and delivers the code for testing
o Month2 – Testing phase, includes SIT –by the month1 end product was release
(YYYYMM) – In parallel, Design & Construction of YYYYMM+1 release is completed
(along with the coding & Unit testing)
- Frequent release – Contains new enhancement, bug fixes, new functionalities – bundled as one
unit – Release on monthly basis – Naming convention is YYYYMM
- AMR – Contains new enhancements, bug fixes, new functionalities done in a year – bundled a
one unit – Release is once in a year – Naming convention is RXX (eg. R17)
- Updates – contains only bug fixes – bundled as component – Daily release – Naming convention
is product_component_seq no (eg. AC_Statement_01)
- After AMR officially launched, no further enhancements done in the release
- T24 Updates
o Bank finds the bug
o Logs on to TCSP (Temenos Customer Support portal) and logs the bug

6
 o Check if there is any existing update for the system
o Select the configuration for their system
o Bank downloads the update from the portal
o Install update in the system using T24 updater
- T24 Upgrade – perform for the banks which already running T24
o Changes done at Code base (Upgrade using TEMP.RELEASE – this is not given to new
clients and given only for existing clients)
o No changes at Configuration
o Modify the data if there is any change in table layout
=====================================================================================
T24 Delivery:
- Ways of Communication – Deal slips & Delivery advices
- Deal slips
o Generated for any application
o Generated during any functions (Input, authorizing, delete, Copy, etc.)
o Provided online
o Is generally printed (i.e. directly to the customer)
o Issued once the transaction inputted
- Delivery advice (works independent of the modules which generated the advice)
o On authorizing a transaction
o Generated for only contract based applications (FT, LD…)
o Generated offline (printed the advice and send it to customer’s postal addr)
o Normally done during COB
- T24 delivery advices – Outward advice (from T24 system to another bank/ customer-
eg.D20171212) - Inward advice (from customer to T24 system-eg.R20171212)
- Outward advice as Account statements, SMS, EMAIL, SECURE MESSAGES, SWIFT
- Inward advice as SWIFT
- DE.CARRIER -> modes of delivery (carriers) storage (Account statements, SMS, EMAIL, SECURE
MESSAGES, SWIFT)
- DE.ADDRESS -> holds the address to which the advice to be sent – holds many records for the
same customer for various delivery channels – On authorizing a customer record the
DE.ADDRESS was created – ID is <Company code>.C-<CustomerID>.<Carrier>.1 – DE.ADDRESS
creates SMS,EMAIL,SECURE MESSAGE & PRINT except SWIFT which is not generated while
creating the customer
- Message type in T24 stored in DE.MESSAGE (eg. For debit MT900, credit MT910)
- Delivery advices are stored in DE.O.HEADER (the id can get it from the FT transaction which
initiated the delivery advice – Delivery Outref field)
o Print advice format is defined in the DE.FORMAT.PRINT application
▪ The status of the advice remains ‘Unformatted’ (i.e. not delivered/ printed) until
the COB runs
o SWIFT – Bank to Bank communication with standard format advices - Three portions
are there,

▪ Header – contains sender & receiver with the message type (like 900,910)
▪ Data portion – contains tags, pre-defined meaning which should be populated
with appropriate data (eg. TAG 20 of MT900 – contains Transaction reference
no, TAG 21 of MT900 –contains Related Reference no, TAG 32A – combination
of 3 values -> Value date, Currency code, Amount

7
 ▪ Trailer
▪ Both Header & trailer (generated automatically) are in standard SWIFT format –
In T24 DE.FORMAT.SWIFT -> provides the format for the data content of
message which is converted to SWIFT
o SMS
▪ Msg generated as per user requirement -> passed to Java Interface using jBase
API called CALLI (XML data)
▪ Interface translate the XML data to client specific XML msg through HTTP/ S
▪ Using SMS Gateway (Clickatell) the message is transferred over SMTP to the
contacts
▪ And equivalent response is passed back to T24 as acknowledgement
o EMAIL
▪ From T24 server the email content is passed as XML package to T24 Email
carrier
▪ From the carrier, it translates xml string to email object
▪ Using open source Java Mail API it transport the message to an SMTP server
o SECURE Message – customer can see when he/ she logs on to T24 through Internet
banking account - in front end all messages are running from the EB.SECURE.MESSAGE
application
▪ From T24 server, the secure message in XML format goes through Secure
Message Interface
▪ Message converted into an OFS string, which is used to create record in
EB.SECURE.MESSAGE application
▪ When customer logs in to T24, he/ she can view the message which is waiting
- Inward Delivery advice (stored in DE.I.HEADER) – From an Interface the SWIFT message is sent
to T24 API. Delivery services identifies the T24 form to which the message belongs to, then
generate the OFS message and then updates the respective application in T24
=====================================================================================
T24 Services:
- Services are stored/ catalogued in TSA.SERVICE application – Helps in automation – these are
programs that runs as background – multithreaded
- Units of Services
o Job –lowest unit of services (implemented as routines), these are catalogued in
PGM.FILE
o Process – collection of related jobs that performs a business function – Process is
catalogued in BATCH application
o Service is an execution of job in a process
o Id of TSA.SERVICE = Id of BATCH
- Each process must have an entry in BATCH application – BATCH record identifies a business
function that we want run as a service in the background –BATCH record contains the list of jobs
that will be executed in a sequence
- In TSA.SERVICE, service.control field tells whether the process need to be start/ stop/ auto start
- ID of TSA.SERVICE/ BATCH(process) is like <Company Mnemonic>/Record id (Mnemonic is must
bcuz the services/batches are company specific. If there is only one bank/company then no
need to have mnemonic)
- BATCH fields

8
 o Batch environment – Foreground /Background (Foreground, the process runs in the
terminal and user will not be able to work on other applications whereas Background,
the process will be disconnect from users terminal and will be executing in the back)
o Job name – contains the routine/job name to be executed
o Frequency – frequency at which the job has to be executed (D – Daily, D nn – every nth
working day, W – Weekly basis (every Friday), M – Monthly (last working day), M nn –
every nth day of the month /previous working day of each month, Y – Yearly (last
working day of the year), Y nn – last working day of nth month, A – Adhoc, manually
specify the date to execute)
o Job status – provides the status of job (0-Ready, 1-Running, 2-Completed, 3-Errors)
o Verification – contains the job name as dependent for the current job to be executed
(Process belonging to other batches cannot be provided)
o Next run date – contains the next date when the job has to run next (for daily & adhoc
this is not populated)
o Last run date – No input field (populated automatically when the current job executed
successfully)
- TSA.SERVICE fields
o Description – description of the service
o Server name – holds the server IP address or host name of the server where the service
needs to be executed
o Work profile – provides the number of copies (multi-threading) that has to run
simultaneously. Holds the Id of record in TSA.WORKLOAD.PROFILE where the no is
identified
o Service control - contains START, AUTO, STOP
▪ START –manually start the service (automatically set for scheduled services)
▪ STOP – manually stop the running service (T24 set this field as STOP when
service completes execution)
▪ AUTO – some service should be set AUTO since they cannot manually set to
START or be scheduled
- Multi-threading process (single threaded is called phantom)
o To run the process as multi-threaded we need tSA & tSM (Service Agent & Service
Manager)
o tSA – executes T24 services, tSM – Manages the execution of services
o tSM is the first tSA – it is pre-configured in TSA.SERVICE – it manages all the services
that be must started or already running – REVIEW.TIME of tSM – check whether the
required number of agents are actually running the assigned job, if no means its
instructs the user to start the required number –tSM will term an agent as ‘DEAD’ if it
doesn’t get reply within the stipulated time(TIME.OUT – specified in COB) from the
agent
o tSA -> Multiple tSA’s can execute simultaneously, each agent run one copy of service –
TIME.OUT, each agent is required to update the tSM that it is performing the task
assigned to it – tSA process at OS level gets killed and a substitute process is started
- No of agents set in TSA.WORKLOAD.PROFILE application (ID of record is any alphanumeric)
- No of agents that run on server is directly proportional to the no of processes available
- No of tSA’s = No of processors * 2
- TSA.PARAMETER -> holds the review time(default-60) & time out (Death Watch is the field name
& default-300) if not mentioned in TSA.SERVICE -> holds only one record (ID is SYSTEM)
- Running service from command line,

9
 o tRun START.TSM –DEBUG
o tRun tSA 1
- Auto service is triggered once the TSA.SERVICE of TSM is set to start and need not to explicitly
set SERVICE.CONTROL of an auto service to ‘START’
- Agents can be monitored using the enquiry as ENQ AGENT.STATUS (and the application used is
TSA.STATUS)
- AGENT.STATUS output fields,
o Agent ID – allocated Agent number for the service
o T24 session no – updated with a unique no that identifies every session in T24
o Server name – name of the server where the agent is running
o Agent.status – status of the agent (RUNNING, STOPPED, DEAD)
o Process Id – OS level process id in which the agent process running
o Current.service – the service that the agent is processing at the moment (like
TSM,PRINT.OUT…)
o Next.service – next service that the agent should process
o Job progress – status of the job being performed
o Last message – the most recent message by the agent
o Como name – name of log record Id that holds the log information of the agent.
Stored in &COMO& directory
=====================================================================================
COB (Close of Business):
- Marks the end of all financial transactions for the day and rolls forward the T24 date to next
business day
- Can be run on every working day of the bank
- Order in which the COB runs for the day, ASRDO (Application, System wide, Reporting, Start of
the Day, Online)
o A – Involves all the application processes eg. Forex, Funds Transfer, etc.
o S –involves all the jobs that are common in T24 (Interest accrual)
o R – Reporting stage ,generation and printing the reports (transaction journals)
o D – Start of the day, involves all start of day operations & date change (executing
standing orders)
o O – Online stage, involves any non-critical reports & process which can be run after the
system moved to Online mode (cleaning of temp files)
- COB Overview
o Initiate COB either in Debug or interactive mode
o System mode changed from Online to Batch mode (reflected in DATES application)
o Execution of COB in ASRDO order
o System changed to Online mode (reflected in DATES application)
o Finally all jobs in online stage are completed
- Batch stage (check illustration in the pdf with diagrams)
o Stage consists of one or more process (suffixed with 3 digit seq no- A000, D999, S099)
o Each process consists of one or more jobs (Process are defined in BATCH application)
- Batch record (BATCH L) – Lists all the batch records(processes), if process linked to batch stage
then it is a part of COB else it is a part of service
(Note: Batch record fields almost same as SERVICE record fields Job name, Frequency, job name,
verification, date fields, job status)
o Batch stage field – contains the batch stage like (A000,D009)
o Process status – status of the batch record/ process (0,1,2,3)

10
- Executing COB services (tSM – control the entire COB process, tSA – executes actual COB
process, First manager should start then followed by agents)
- tSM & tSA on multi server (Multi-server need to be installed (MS) if COB is to be run on Multiple
application servers) –In this, each server will have a tSM - number of tSA is based on the
capacity of the server (i.e. No of tSA = No of Processors*2)
- In TSA.SERVICE application, COB and TSM pre-configured as services (online services)
- Running COB
o Before running COB – check EB-EOD.ERROR for any unresolved errors are present from
previous run
o Set Service.control field to START in TSA.SERVICE
o Launch TAFJ shell -> type tRun START.TSM –DEBUG (interactive mode) – displays the
agents
o Open other TAFJ shell -> type tRun tSA 1 (1 is allocated agent id)
- DATES in COB – one record per company with id as Company code (next day is decided when all
the process/transactions for the current day was completed by COB)
- Date changes during COB
o Before 1st run initially 1 record is in Dates application
o Start COB, runs A001-> a job called EB.CYCLES.DATEs is executed which creates a record
with Id as <Company code>-COB (this record cannot be deleted after COB & overwritten
during next COB)and updates the existing record dates to + 1 (today/ next/ last)
o When COB reaches D000-> a job called B.DATE.CHANGE executed which changes the
dates for record with ID <company code>-COB in DATES application
o Beginning of Online stage-> job called BATCH.DATE.RESET executed which updates the
Next run date for all the jobs executed today (excluding job with frequency D & A). Also
PROCESS.STATUS & JOB.STATUS fields in BATCH records set to 0 (as a part of COB
framework)
o COB doesn’t use the DATES record with ID <company code> (this record used for new
transactions coming into system while COB is running when NS module is installed) for
processing
- Non-Stop module
o COB supports 24 hrs non stop processing – When NS is installed, T24 is available for
input when COB is in-progress
o Uses Dates record with id <company code>
o During COB running, value date is next working day
- Sorting of Jobs – tSA calls a routine called S.JOB.RUN -> invokes a routine EB.SORT.BATCH (only
once) which sorts the jobs in ASRDO order and give it to tSA
- Monitoring COB
o At TAFJ- > type tRun EX -> COB.MONITOR (classic User interface) is opened which
displays the COB processing for the batch stages and the output is autorefreshed
- Enquiring COB.PROGRESS
o Displays the COB progress, while executing the enquiry we can set autorefresh which
keeps refreshing & shows the % of job completion
- EB.EOD.ERROR – the file which holds the errors encountered during COB (ID is <company
code>.<date(YYYYMMDD)>) and used to track down the cause of the problem encountered
during COB
o Contains one record per company per day during COB and the details of the errors can
be viewed in EB.EOD.ERROR.DETAIL application (id is present in EB.EOD.ERROR- Detail
key field holds the id)

11
 o Fix required field – updated by system as ‘YES’ - indicates that the error should be
resolved before next COB run
o EB.EOD.ERROR.DETAIL – contain the name of process, name of job, routine from which
the error was generated
o Date Resolved field – need to be update with the date that the error was fixed (done
before COB is started the next day)

Enquiry:
Drill down example:
Parent enquiry – CUSTOMER as (CUSTENQ)
Child enquiry – ACCOUNT as (ACCENQ)

Open Parent enquiry to link the child and update the below fields,
Enquiry name: ACCENQ (provide child enquiry name)
Selection criteria field: CUSTOMER (operation name from child enquiry) EQ ID (Field name from parent
enquiry)
Label field: ID 1 (hyperlink to invoke child enq)

Context based flow

In parent enq update the fields as,
Enquiry name: (Version name with complete command) CUSTVER I F3
Sel criteria: CUSTOMER> ID (Application name of Version > Field name of parent enquiry)

In version update the fields as below,

Autom field: DEBIT.ACCT.NO
Auto new field: ACCOUNT>ID (Parent Application name> Parent field name)
=====================================================================================
Questions & Answers
1. Como name – name of log record Id that holds the log information of the agent. Stored in
&COMO& directory (log in which folder)
2. AGENT.STATUS holds the name of the log file
3. COB is run on 22 feb 2014. hence we can conclude that on completion of COB, the T24 date will
be 23 feb – False (on completion of COB it will check for the dates in holiday table, if next day is
holiday/ non-business day means it will update the next business day)
4. To check if 3rd Dec 2014 is a working day we can refer to the DATES application - holiday is the
answer (DATES have only the next last and today dates where as if u want to know the
particular day which is not immediate day u have to check in HOLIDAY table for the month and
the year they gave u HOLIDAY table consists of the entire year in calendar)
5. What is the order of COB service run - ASRDO
6. Where we can set the number of authorizers? No of auth in versions
7. Self-authorizing user other name Comma version/ Zero authorizing
8. An user is typing the password incorrectly more than 5 times but the log is not captured what
the issue – no of retries in SPF not set
9. Where we can see the log information of above – EB.REKEY.RETRIES (this is a temporary live
table get update as the retries entered)
10. Can we set the field as non-mandatory and how we can set – mandatory field la in versions (to
set the field as mandatory & non-mandatory)

12
 11. Can we make field as mandatory in local fields & how – yes.. using minimum char field we can
set it as mandate
12. TSM full form – T24 Service Manager
13. Record put on hold will be stored in - Unauthorized file
14. If a user should have access to all applications what has to be done , in which field 
Application field  ALL.PG
15. Operation field will be defaulted with field .name when we give which name in field .name – in
field name give ss name and validate then the operation name will be defaulted
16. Advices will get created only on commit – False (only on authorization)
17. Mode of communication will be stored in – DE.CARRIER
18. Types of message will be stored in - DE.MESSAGE
19. SWIFT message can be created as users wish –False (should be created as SWIFT Standard)
20. Which releases not given to new client – TEMP.RELEASE
21. In enquiry drill down/ context based flow associated enquiry/versions may be from different
applications – True
22. In versions, associated versions should be different application – False (always should be same)
23. If you want to see the menu on home screen when user logs in, which command is used –
HELPTEXT.MENU (will be present on screen) & HELPTEXT.MAINMENU (Will be sub menus)
24. IF a user is set with Super.user functionality then he can able to execute command line
25. IF author has to verify the value by entering twice, which functionality – Rekey function
26. Can we use rekey concept for Comma version – False (Atleast one authorizer is needed to do
rekey)
27. New build will contain bug fixes as well – True
28. In DS while creating version mandatory fields will be automatically selected if u select the
mandatory fields along with? we have to remove it from the mandatory list as it is system
generated - customer i
29. If u want to see the list of customer what cmd is used – CUSTOMER L
30. Symbol used for enquiry - % and –
31. In a version, if a field has to be added what function will use – sub value (>) & Multi value (+)
32. In company table, no of authorizers(Field called Default no of authorizers) can be set at
company level
33. Validation routines in t24 begin with IN2
34. Assigned products for bank can be verified from COMPANY table in Application field
35. AT runtime, fixed selection condition cannot be changed

20-12-2017:---- Sorry forgot one question

1. Updates comprises of – bug fixes
2. T24 today’s date can be seen in which application – DATES
3. PGM.FILE contains – all applications & sub-routines
4. All sub-routines have entry in which application –PGM.FILE
5. Versions which is true – options given with associated Versions (same application name should
be there)
6. Which is not true about date fields in COB  Last run date should be inputted for job with A
frequency (Last run date is a no input field for all jobs with all frequencies)
7. In COB, the date change rolls over which application – DATES

13
8. Modes of communication of delivery advices stored in -DE.CARRIER
9. On authorizing a customer record, in which application the record get created automatically –
DE.ADDRESS
10. Related to Help menus---- > Question is like sub menus LIST CUSTOMER & LIST ACCOUNTS need
to be attached to main menu called Enquiry, provide the steps
11. USER.SMS.GROUP question like  Three telllers should assigned with same privileges. How we
can do this? Ans: Create a record in USER.SMS.GROUP and create 3 individual records in USER
and then in the application field provide the USER.SMS.GROUP ID
12. Which is not true? (Pls check the answer)
a. AUTHORISED record only can be REVERSED
b. Record in IHLD status can be deleted
c. AUTHORISED record can be deleted
d. Unauthorized record can be deleted
13. File sharing, which is true Ans:c & d (c. CUS file type may or may not shared & d. FIN type should
not be shared)
14. Local field related question, Bill.no, Bill date, (another field) to be given as associated fields. Ans:
Create fields in local table then attached the fields in sub association fields in local ref table
15. Which of the fields will be present in all applications Ans: All the above
(Overrides,Reversed,Audit)
16. While entering ENQUIRY %CUSTOMER, a selection criteria is provided as SECTOR EQ 1001 1002
1003 Ans: This is a valid selection criteria
17. Which is not true?
a. Multiple Fixed selection criteria with OR relational operator
b. Multiple Fixed selection with AND operator
c. For dynamic selection criteria, need to specify OR in Rel oper field
18. Enquiry to query agent status – AGENT.STATUS
19. Which is true about the Batch? Ans: Process status moved to 2 only when job status is 2
20.

14