PRG5 (1) .Basic Version Routines-R10.01

1. Welcome to the “Basic Version Routines” learning unit.
This learning unit will enable you

to understand the concept of creating version routines in T24. You will learn how to create
and use three types of version routines namely Validation routines, Input routines and
Authorization routines.
PRG5.BasicVersionRoutines – R09.01 1
After completing this learning unit, you will be able to:
•Explain the need for version routines

•Create different version routine
1. The VERSION utility is used to customize an application in T24. Not only do Versions
allow you to create customized screens, hide fields that are not required, default values
in the fields, make normal fields as no input fields, make non mandatory fields
mandatory etc, they also allow you to attach local routines that can enhance the way an
application works based on client requirements.
2. Routines that are attached to the VERSION application in T24 are called Version
Routines. There are many types of version routines. This learning unit will teach you
three basic types of version routines.
An example will give you a clear picture of what a version routine is. In the actual
FUNDS.TRANSFER application, DEBIT.CURRENCY is a mandatory field and has to
be input by the user. But what if you want this field to be defaulted once you enter a
value in the field DEBIT.ACCT.NO and tab out? How can you achieve this? By writing
local code. Where will you attach this code? Can you attach it to the FT application? No,
so this is where Version routines comes into picture. You can write a routine to pick up
the currency of the account given in DEBIT.ACCT.NO field from the ACCOUNT
application and write it into the filed DEBIT.CURRENCY. You have to attach this
routine in the version record of the FT application.
Now that you have an idea of what a version routine is, from where do you think the values
will be picked up and processed in the routines? Can the routine directly access the value
input in the fields in the record?
No.
Version routines act on the values that are held in the common variables. The values input in
the fields of a record will be stored in different common variables. Most of the common
variables used in T24 are defined in a file named I_COMMON under T24.BP
Version routines use different common variables which are initialized at different points in
time.
The ID of the record that is currently open is held by a common variable ID.NEW which is a
Dynamic array. A dynamic array is a data structure that can be resized and allows elements
to be added or removed. All variables in Jbase Basic are by default dynamic arrays unless
defined as dimensioned.
When the record is closed or committed or authorized the value in this variable gets flushed.
The variable R.NEW holds the record of an application that is currently in use. Once the
record is committed, the value in this variable gets cleared. ID.NEW holds the ID of the
currently opened record, while R.NEW holds the actual record. ‘R’ in the variable name
stands for ‘Record’.
It is defined in I_COMMON as DIM R.NEW(C$SYSDIM) since it is a dimensioned array,

where C$SYSDIM is equal to 500.
No application in T24 has more than 500 fields, so the size of R.NEW is restricted to 500.
The day it exceeds 500, the value in C$SYSDIM should be increased accordingly.
Each position in a dimensioned array in T24 in turn is a dynamic array.
For example when a user creates a new CUSTOMER record, the variables ID.NEW and
R.NEW will hold the ID and the actual record respectively. Once the record is committed,
data is flushed from the variables ID.NEW and R.NEW.
1. If an unauthorized record exists for the currently opened record in any application, this
variable will hold the ID of the unauthorized record.
2. This variable is a Dynamic array
3. The ID of the live and unauthorized record will be the same. This variable enables us
to know, programmatically whether or not an unauthorized record exists for the
currently opened record.
1. R.NEW.LAST variable holds the actual unauthorized record if any for the currently
opened record ID in any application. It holds the last saved unauthorized record.
ID.NEW.LAST holds the ID of the unauthorized record for the currently opened record
if it exists, while R.NEW.LAST holds the actual unauthorized record.
2. This is a Dimensioned array which comprises of 500 dynamic arrays
3. This variable is defined in I_COMMON as DIM R.NEW.LAST(C$SYSDIM)
If the user opens the CUSTOMER record 111178 in authorization mode, R.NEW will hold
the actual record opened and R.NEW.LAST will hold the unauthorized record pertaining to
the currently opened record. In this particular example, both these variables will hold the
copy of the same record. When the record is authorized, data is flushed from the variables
ID.NEW , R.NEW, ID.NEW.LAST and R.NEW.LAST. Values from R.NEW only are written
into the database when record is authorized.
1. This variable holds the ID of the authorized record if exists for the currently opened
record in any application. This variable is a Dynamic array
2. ID.OLD enables you to check programmatically whether or not the currently opened
record has an already authorized record.
1. The variable R.OLD holds the actual authorized record if any for the currently opened
record ID in any application. ID.OLD holds the ID of the authorized record for the
currently opened record if it exists, while R.OLD holds the actual authorized record.
2. This is a Dimensioned array which comprises of 500 dynamic arrays
3. This variable is defined in I_COMMON as DIM R.OLD(C$SYSDIM)
When the user amends the authorized CUSTOMER record 111178, by changing the
SECTOR field, R.OLD will have the old authorized record where as R.NEW will hold the
amended customer record. Any changes are only reflected in R.NEW. When the record is
committed, data is flushed from the variables ID.NEW , R.NEW, ID.OLD and R.OLD.
If the user open existing INAU record 11178 which has a previously authorized record, in
authorization mode, then R.NEW will hold the currently opened record, R.NEW.LAST will
hold the last saved unauthorized copy of the record and R.OLD will hold the last authorized
copy. Once the record is authorized, data is flushed from all the variables. Values from
R.NEW only are written into the database when record is authorized. The old authorized
record R.OLD with SECTOR 1000 is moved to history file with the ID as 111178;1.
• Validation routines as the name implies are used to validate data entered in a record in
any application. All the variables that you have just learnt can be used to write a
validation routine.
• These routines can also be used to default values into fields on committing the record.
• For the validation routine to get executed, the name of the routine must be specified in
the field VALIDATION.FLD in the particular version record for an application.
• Validation routine is triggered on clicking the validate button in a record.
• This routine also gets invoked after a user presses the ‘Tab’ or the ‘Enter’ key from a
field which is set as a hot field.
What do you mean by a hot field? How can you set a field in an application as a hot field?
In this task you will learn to create a version, write a validation routine and attach it to the
version.
1. Create a version for the FUNDS.TRANSFER application with the following fields
TRANSACTION.TYPE
DEBIT.ACCT.NO
DEBIT.CURRENCY
DEBIT.AMOUNT
DEBIT.VALUE.DATE
CREDIT.ACCT.NO
CREDIT.CURRENCY
2. Set the field DEBIT.ACCT.NO as a hot field. After entering a value in this field and tabbing
out, currency field should be defaulted.
3. Set the field DEBIT.CURRENCY as NOINPUT field
The first step is to create a version record for the FT application with the necessary fields
and set the field ATTRBIS to HOT.FIELD for DEBIT.ACCT.NO and the field
DEBIT.CURRENCY as NOINPUT field.
The next step is to write a subroutine to populate the currency of the account in the field
DEBIT.CURRENCY once you tab out of the field after entering the value in the field
DEBIT.ACCT.NO.
Extract the account number entered from the field DEBIT.ACCT.NO. Using the account
number entered, read the ACCOUNT file and extract the relevant record. From the record,
extract the currency of the account and display it in the field DEBIT.CURRENCY.
Compile and catalog the subroutine using EB.COMPILE
Make an entry in EB.API application for the version routine. Ensure that this routine does not
get triggered when the record is committed as all validation routines, by default, get triggered
when the record is committed as well.
Note – Call to REBUILD.SCREEN not required for this routine to work on the Browser. It is
required for it to work in the CUI of T24.
The third step is to make an entry in EB.API application for the version routine. Set the field
PROTECTION.LEVEL to NONE and the field SOURCE.TYPE to BASIC and authorize the
record. The ID of the record should be the name of the subroutine.
Attach the routine to the field DEBIT.ACCT.NO in the version record in the fields
VALIDATION.RTN and VALIDATION.FLD
After you enter the debit account number and click the tab button, the currency will be
defaulted in the field DEBIT.CURRENCY
When you check the debugger mode, you can see how the values in the common variable
R.NEW changes from time to time. It first takes the account number that is input by the user,
reads the ACCOUNT record gets the currency and populates it into the validation routine.
The validation routine gets triggered only on committing the record. After you commit the
record in Browser, it goes to debug mode. At this point note that the request has not yet
reached TC server. Therefore when you get into debug mode you must commit the record
by typing ‘C’ at the debugger prompt for the request to hit TCServer and then view the
values in the variable.
But from where can you actually see the values in this common variable.
To debug the validation routine, you have to specify the DEBUG statement in the routine.
Before you specify the debug statement, ensure that you configure the DEBUG option in a
file called jboss-log4j.xml which can be found under the following path in jboss,
jboss-4.2.3.GA\server\default\conf.
You already know that the validation routine is triggered only when the commit button is
clicked. But what if you want to validate a value in a particular field just after you tab out
of it? Is this possible in Browser? Yes.
1. To achieve this, when Browser is used as the front end, field level validations will take
place only if a field is set as a hot field. Set up the field ATTRIBS in the VERSION
application as HOT.FIELD to define any field in an application as hot field.
2. Hot field are shown with a fire symbol next to them.
3. Defining a field as a hot field, automatically sends a validation request to the server on
changing the value in a field. Once you tab out of a hot field after inputting a value in
Browser, the validation routine is triggered.
Now can you continue using the variable R.NEW to get value into the field when you set a
field as HOT.FEILD?
COMI is the common variable that is to be used when you set a field as a HOT.FIELD in
Browser. COMI holds the last input field value in a record. This variable is a dynamic array
defined in I_COMMON. Values get flushed when the record is exited or committed or
authorized.
You can use the previous task to understand the use of the common variable COMI. The
first step is to create a version record for the FT application with the necessary fields and set
the field ATTRBIS to HOT.FIELD for DEBIT.ACCT.NO and the field DEBIT.CURRENCY as
NOINPUT field.
A copy of the routine used previously can be modified to use the common variable COMI
instead of R.NEW.
If you do not use the same routine name you will have to create an EB.API entry
accordingly.
Note – Call to REBUILD.SCREEN not required for this routine to work on the Browser. It is
required for it to work in the CUI of T24.
After you enter the debit account number and click the tab button, the currency will be
defaulted in the field DEBIT.CURRENCY
When you set a field as HOT.FEILD, the variable COMI takes the last input value in a field. If
you can analyze the difference between using COMI and R.NEW, COMI takes the value
immediately after input whereas R.NEW takes in the value only after the record is
committed.
Though COMI is used during field validation , it is insignificant during commit phase. COMI
can be used is the cross validation routine (R5) or .VALIDATE routine of an application
When a record is commit, for every field in the application, the validation routine attached at
the current application version (if any) would be triggered which is then followed by either
FIELD.INPUT/FIELD.MULTI.INPUT/OFS.FIELD.INPUT as the case may be. These routines
consider that the variable COMI holds the latest updated field value and assigns the value to
R.NEW. Hence if it is required to default any value for a field from the version routine, one
should use COMI.
PRG5.Basic Version Routines-R8.02 29

An input routine can be used to provide additional checking on the values input.
• Input routine gets invoked just prior to committing a transaction in the unauthorized
stage. They are invoked prior to the final update of files at the unauthorized stage of a
transaction.
• These routines are invoked after all standard default and validation processing is done.
• Input routine gets invoked even if the record is put on hold
• Routines at this stage may be used to perform additional checking or override
processing
• Input routines are attached in the field INPUT.ROUTINE in the VERSION application.
This is a multi value field and therefore multiple routines can be attached at this stage.
The text to be entered in this field should be a valid subroutine name that can be
executed.
• When the Input Routine is invoked, the common variable COMI is not be available to
extract any value.
• R.NEW should be used to extract necessary information from a record.
• Many user defined error messages can be part of an input routine. To display error
message, the common variable ETEXT is used.
• STORE.END.ERROR is a T24 subroutine that is capable of displaying the error
message stored in ETEXT.
Syntax is ETEXT = <“ERROR MESSAGE”>
CALL STORE.END.ERROR
By default, STORE.END.ERROR will display the error message in the left top corner of the
browser screen. The variables ‘AF’ which holds the field position, ‘AV’ which holds the multi
value position and ‘AS’ which holds the sub value position defined in I_COMMON are used
to display the error message next to a particular field in CLASSIC mode. In BROWSER
mode only if these variables are set, the system will display the field name pertaining to
which the error was generated.
In this task you will learn to write an input routine and attach it to the version.
1. When a user commits a record in a version of the FUNDS.TRANSFER application, a
check has to be made to see whether the Debit Account Currency and the Credit Account
Currency are the same. If not, an error message “DEBIT AND CREDIT CURRENCY NOT
EQUAL” has to be displayed
2. Fields that need to be displayed as part of the version are
TRANSACTION.TYPE
DEBIT.ACCT.NO
DEBIT.CURRENCY
DEBIT.AMOUNT
DEBIT.VALUE.DATE
CREDIT.ACCT.NO
CREDIT.CURRENCY
The first step is to create a version record for FT with all the necessary fields. This learning
unit does not teach you how to create a version.
The next step is to write a subroutine that will extract the debit and credit currency, compare
the values and throw an error if the values are not equal. Compile and catalog the routine.
Attach the routine in the version record in the field INPUT.ROUTINE
If the debit and credit currency are not equal, the error message is displayed.
When you get into debug mode, you can actually see how the variables are assigned
values. Note that the field number assigned to the variable ‘AF’ is the field number in the
actual application and not in the version. Note that when the currency is not the same, the
value is populated into the variable ‘ETEXT’.
In this workshop, you will learn to create an input routine.
When a user commits a record in a version of the FUNDS.TRANSFER application, a check
has to be made to see whether the debit amount and the credit amount are the same. If not,
an error message “Debit And Credit Amounts Do Not Match” has to be displayed.
Fields that need to be displayed as part of the version

Transaction Type
Debit Account Number
Debit Currency
Debit Amount
Debit Value Date
Credit Account Number
Credit Currency
• Authorization routine gets executed at the authorization stage of a transaction. This
routine gets invoked just prior to the final update of files.
• Routine called at this stage can be used to update local files
• Before this routine is invoked, all standard default and validation processing would have
taken place.
• Authorization routine is attached in the VERSION application in the field
AUTH.ROUTINE. The name of the routine should be an existing program that is
executable.
• This routine is invoked after a write is made to the buffer. Any changes made to R.NEW
will not reflect in the record unless a WRITE is made explicitly.
• In this case, a call to F.WRITE should be made first even before JOURNAL.UPDATE is
called as this is taken care of by T24 core.
You will now learn to create an authorization routine.
1. Once a record in a version of the FUNDS.TRANSFER application is authorized, the
following details from the transaction need to be extracted and written on to a flat file named
TEMENOS.TRAINING for interface purposes all delimited with a single space
DEBIT.ACCT.NO
CREDIT.ACCT.NO
DEBIT.VALUE.DATE
DEBIT.AMOUNT
DEBIT.CURRENCY
2. ID of the record in the flat file should be the ID of the FT record
The first step is to create a VERSION record for the FT application
The second step is to create a flat file under the HOME directory.
CREATE.FILE TEMENOS.TRAINING TYPE=UD
The third step is to write a routine that will extract the required values from the record and
write to the flat file. Use the command OPENSEQ to open the file.
Use the command WRITESEQ to append the data to the file. If the routine fails to update the
file, then the error message should be displayed. Compile and catalog the routine.
Note that the variable R.NEW still contains the record and has not yet been flushed to the
database. So, though you can modify R.NEW in an authorization routine, it is not
recommended as all the validations on the record are already complete.
Attach the routine in the version record in the field AUTH.ROUTINE
Input an FT record in the version and authorize the record.
Note the contents of the flat file. It holds the record created using the FT version.
This workshop will help you to write an authorization routine.
Once a record in a version of the CUSTOMER application is authorised, the following details
from the transaction need to be extracted and written on to a flat file named
TEMENOS.XX.CUS.INTERFACE for interface purposes.
XX – Is your name
ID of the record in the flat file needs to be the Customer ID
Following field’s values need to be stored in the flat file all delimited with a
single space
Mnemonic
Sector
Nationality
Language
The above operation needs to be done only if the record being authorised is a new customer
record
1. QUESTION : The value of the common variable C$SYSDIM is equal to 500
TRUE
FALSE
2. QUESTION : R.NEW.LAST holds the ID of the unauthorized record for the currently opened record.
TRUE
FALSE – Holds the actual record
3. QUESTION : ID.OLD holds the ID of the last authorized record.
TRUE
FALSE
4. QUESTION : HOT field should be set in VERSION application
TRUE
FALSE
5. QUESTION : COMI holds the last input field value
TRUE
FALSE
6. QUESTION : ETEXT holds the override message to be generated
TRUE
FALSE – Error message
7. QUESTION : All validation routines should have an entry in the EB.API application
TRUE
FALSE
8. QUESTION : Input routine is invoked on committing a record in authorized stage
TRUE
FALSE – Unauthorized stage
9. QUESTION : STORE.END.ERROR is a routine used to display the error message
TRUE
FALSE
In this learning unit/course, you learnt about the basic version routines in T24
You will now be able to:

•Explain the need for version routines
•Create different version routine
Slide 52
n11 CHECK THE PROPERTIES AND AUTHORING CONTRIBUTIONS

nausheen, 2/26/2010

PRG5 (1) .Basic Version Routines-R10.01

Uploaded by

Document Information

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

PRG5 (1) .Basic Version Routines-R10.01

Uploaded by

Copyright:

Available Formats

1. Welcome to the “Basic Version Routines” learning unit.

This learning unit will enable you

•Explain the need for version routines

It is defined in I_COMMON as DIM R.NEW(C$SYSDIM) since it is a dimensioned array,

Each position in a dimensioned array in T24 in turn is a dynamic array.

PRG5.Basic Version Routines-R8.02 29

2. Fields that need to be displayed as part of the version are

Attach the routine in the version record in the field INPUT.ROUTINE

Fields that need to be displayed as part of the version

2. ID of the record in the flat file should be the ID of the FT record

CREATE.FILE TEMENOS.TRAINING TYPE=UD

You will now be able to:

n11 CHECK THE PROPERTIES AND AUTHORING CONTRIBUTIONS

You might also like