Click to edit Master text styles

USEFUL ROUTINES IN VERSION

Presented by: Second level
Md. Aminul Islam. Third level
Software Engineer.
OBJECTIVE

After completing this lesson, you should be able to:

• Understand the need for version routines.
•Understand Various types of version routines.
• Understand execution of Version routines.
• Understand various fields in the version application to which
routines can be attached.
VERSION ROUTINES

• Routines attached to version application are used to perform extra

validation and functionality.
• Used to default and update values
• Used to update values in other Tables
• Values are extracted and updated through the common variables in
T24.
TYPES OF VERSION ROUTINES

Version Routines

Validation Routine
Input Routine
Authorization Routine
Auto Field Routine
Id Routine
Check Record Routine
After Unauth Routine
Before Auth Routine
INPUT
INPUT ROUTINE
ROUTINE
INPUT ROUTINE

• Input Routine gets invoked the moment the record is committed

(When F5 is pressed).
• Input Routine is used to
–to provide additional validation at input stage
• Multi value field and hence multiple routines can be attached.
• When multiple routines are attached, they are executed in the order
in which they were specified in the version.
• Entry in EB.API is necessary.
EXAMPLE

Write a routine for the Funds Transfer version , that will check the
DEBIT AMOUNT greater than 100. If not, an error message,
“Debit amount must be grater than 100” needs to be
displayed when the user commits the record
SOLUTION STEPS

• Create a Version for FT application with all Mandatory fields.

• Write a routine for the requirement and compile and catalog.
• Create a EB.API entry.
• Attach the routine to the FT version.
ALGORITHM

• Extract the DEBIT.AMOUNT from the FUNDS.TRANSFER version

using variable ‘R.NEW’
• Check the debit greater than 100. If not flash an error message
“Debit amount must be grater than 100”.
• Call the core routine to display the error message. CALL
STORE.END.ERROR
ROUTINE

SUBROUTINE FT.INP.RTN
$INSERT GLOBUS.BP I_COMMON
$INSERT GLOBUS.BP I_EQUATE
$INSERT GLOBUS.BP I_F.FUNDS.TRANSFER
Y.DEBIT.AMOUNT = R.NEW(FT.DEBIT.AMOUNT)
IF Y.DEBIT.AMOUNT LE 100 THEN
AF=FT.DEBIT.AMOUNT
ETEXT = "Debit amount must be grater than 100"
CALL STORE.END.ERROR
END
RETURN
END
ATTACHING THE ROUTINE

• EB.API ENTRY

• Attach the routine to the FT version in field 63.

• Now try to input a new FT transaction

• Error message that appears when the record is committed with
DEBIT AMOUNT less than 100.
OUTPUT

• After committing the output will be

AUTHORIZATION
AUTHORIZATION ROUTINE
ROUTINE
AUTHORIZATION ROUTINE

• Gets invoked at the time of authorization of a transaction.

• Multi value field and hence multiple routines can be attached at this
stage.
• Authorization Routines are used to:
–to update Local reference fields at authorization stage
• At this stage all the field-level validations have been completed.
• Entry in EB.API is required.
• Authorization routine gets executed after writing a record into a live
file. Hence we cannot restrict the authorization by setting error
variable.
• Values will be in common variable R.NEW.
EXAMPLE

• Write a ROUTIN that will display a new version to create an account

after authorized a customer.
SOLUTION STEPS

• Create a version for the CUSTOMER application with all mandatory

fields and make no of authorizers as ‘1’
• Write a routine for the requirement
• Create an EB.API entry
• Attach the routine to the Customer version
ROUTINE

SUBROUTINE AUT.RTN
$INSERT I_COMMON
$INSERT I_EQUATE

IF APPLICATION = 'CUSTOMER' AND V$FUNCTION = ‘A‘ THEN

INPUT.BUFFER = C.U:' ACCOUNT, I ':C.F
END
RETURN
END
ATTACHING THE ROUTINE

• EB.API

• Attach the routine to the customer version in field 64.

• Now try to input a new customer and authorize it.

• Check whether a new account is created on authorization of
customer .
OUTPUT

• Authorization of customer

• After authorization
AUTO
AUTO FIELD
FIELD ROUTINE
ROUTINE
AUTO FIELD ROUTINE

• They get executed after the id of the record is input.

• Can be used to perform any special editing of a record before it is
displayed to the user.
• Attached to the field Auto New Content in the Version Application.
• Entry in PGM.FILE is required.
• ID.OLD is a common variable that will hold the ID of the authorized
record.
• ID.NEW is a common variable that will hold the ID of the Currently
Opened record.
EXAMPLE

• Write a routine that will display the total number of accounts of a

particular Customer in the local reference field TOTAL.ACCOUNTS.
If a new Customer record is input then the calculation should not be
performed.
SOLUTION STEPS

• Create a version for the CUSTOMER application with all mandatory

fields and the local reference field TOTAL.ACCOUNTS.
• Write a routine for the requirement and compile and catalog.
• Create an PGM.FILE entry
• Attach the routine to the Customer version to the field
AUTO.NEW.CONTENT
ROUTINE

SUBROUTINE AUTO.CUSCNT
$INSERT GLOBUS.BP I_COMMON
$INSERT GLOBUS.BP I_EQUATE
$INSERT GLOBUS.BP I_F.CUSTOMER
$INSERT GLOBUS.BP I_F.CUSTOMER.ACCOUNT
GOSUB INIT
GOSUB OPENFILES
GOSUB PROCESS
RETURN

INIT:

FN.CUS.ACC = 'FBNK.CUSTOMER.ACCOUNT'
F.CUS.ACC = ''
Y.CUS.ID = ID.NEW
R.CUS.ACC = ''
Y.CUS.ACC.ERR = '‘
RETURN
ROUTINE (CONT.)

OPENFILES:
CALL OPF (FN.CUS.ACC, F.CUS.ACC)
RETURN

PROCESS:
IF ID.OLD = '' THEN ;*If it is a new Customer Record
R.NEW(EB.CUS.LOCAL.REF)<1,10> = 0 ;*No calculation is required
END
ELSE
CALL F.READ(FN.CUS.ACC,Y.CUS.ID,R.CUS.ACC,F.CUS.ACC,Y.CUS.ACC.ERR)
IF Y.CUS.ACC.ERR NE '' THEN
R.NEW(EB.CUS.LOCAL.REF)<1,43> = 0
END
ELSE
R.NEW(EB.CUS.LOCAL.REF)<1,43> = DCOUNT(R.CUS.ACC,FM)
END
END
RETURN
END
ATTACHING THE ROUTINE

• PGM FILE ENTRY

• Attach the routine to the customer version.

• Now try to input a customer and authorize it.

OUTPUT
CHECK
CHECK RECORD
RECORD ROUTINE
ROUTINE
CHECK RECORD ROUTINE

• This routine is called after the ID is Supplied and Validated.

• These routines could be used to alter the field attributes.
• This will get invoked when the following functions I(Input),
D(Delete), A(Authorise) and R(Reverse) are used.
• It is attached to the field CHECK.REC.RTN.
EXAMPLE

• Write a subroutine that will restrict any user trying to open a Live
Customer Record which was not input and authorized by him and
will display an error message “Access Restricted”
SOLUTION STEPS

• Create a version for the CUSTOMER application with all mandatory

fields.
• Write a routine for the requirement and compile and catalog.
• Create an EB.API entry
• Attach the routine to the Customer version to the field
CHECK.REC.RTN prefixed with an @symbol.

 Operator
This is a dynamic array that has been defined in the I_COMMON file
that contains the name of the currently signed on user.
ALGORITHM

1.Check if the record being opened is a new Customer record. If so, no

processing should be done and the user should be able to open the
record.
2.Check if the record is an unauthorized record. If so, no processing
should be done and the user should be able to open the record.
3.Extract the value of the field INPUTTER.
4.Check if the current user is same as the inputter. If not, then display
the error message “Access Restricted”
ROUTINE

SUBROUTINE CHECK.REC.RTN
$INSERT GLOBUS.BP I_COMMON
$INSERT GLOBUS.BP I_EQUATE
$INSERT GLOBUS.BP I_F.CUSTOMER

THIS.OPERATOR.OK = ''
IF NOT (R.NEW(EB.CUS.INPUTTER)) THEN RETURN ;*could be a new record
IF R.NEW(EB.CUS.RECORD.STATUS) THEN RETURN ;*Could be an unauthorised
record

INPUTTERS = R.NEW(EB.CUS.INPUTTER)

IF FIELD(INPUTTERS,'_',2) = OPERATOR THEN

THIS.OPERATOR.OK = 1
END ELSE
AUTHORISER = R.NEW(EB.CUS.AUTHORISER)
IF FIELD(AUTHORISER,'_',2) = OPERATOR THEN
THIS.OPERATOR.OK = 1
END
END
ROUTINE (CONTD.)

IF NOT(THIS.OPERATOR.OK) THEN
E = 'Access Restricted'
CALL ERR
!MESSAGE = 'REPEAT'
END

END
ATTACHING THE ROUTINE

• EB.API ENTRY

• Attach the routine to the customer version.

• Now try to input a customer and authorize it.

OUTPUT

• Trying to input by using different user

• Final output
AFTER
AFTER UNAUTH
UNAUTH ROUTINE
ROUTINE
AFTER UNAUTH ROUTINE

• This routine is called while committing a new record or existing

record after making changes.
• This routine is called after Input Routine and the record is written to
$NAU file.
• It is attached to the field AFTER.UNAU.RTN.
EXAMPLE

• There is a requirement where in, when a transaction is committed

using a version of the FT application, the user should be taken to
another version in order to input the charges (if any).
SOLUTION STEPS

1.Check if the application is FT

2.Check if the version used is the version to which we are attaching
this subroutine. (The above two checks are not absolutely
necessary).
3.In case this routine is going to be made common to all versions of
the FT application and if you still want to execute this routine only
for the FT,PARENT Version, then this check is required.
4.Check if the function used is ‘I’, If the function used is ‘I’, then
execute the next version (FT,CHILD)
ROUTINE

• PGM.VERSION
–This is a common variable defined in I_COMMON that contains the
name of the currently opened version.
Example : CUSTOMER,INPUT
APPLICATION : CUSTOMER
PGM.VERSION :,INPUT
• INPUT.BUFFER
–This is a common variable defined in I_COMMON which is capable
of containing any input that a user wishes to execute from the
command line.
Example
INPUT.BUFFER = C.U:”CUSTOMER I” : C.F
C.U : Ctrl U Enter(F1) -> will go to the command line
C.F : Ctrl F Enter(F3) -> Used to obtain a new id
ROUTINE(CONTD.)

• V$FUNCTION
–This is a common variable defined in I_COMMON that contains the
function that is being currently chosen by the user.

SUBROUTINE AFTER.UNAUTH.RTN
$INSERT GLOBUS.BP I_COMMON
$INSERT GLOBUS.BP I_EQUATE
$INSERT GLOBUS.BP I_F.FUNDS.TRANSFER

IF APPLICATION = "FUNDS.TRANSFER" AND PGM.VERSION = ",EXPRTN"

AND V$FUNCTION = 'I' THEN
INPUT.BUFFER = C.U:" ":APPLICATION:",MIG":" I ":C.F
END
RETURN
END
ATTACHING THE ROUTINE

• EB.API ENTRY

• Attach the routine to the FT version

•
BEFORE
BEFORE AUTH
AUTH ROUTINE
ROUTINE
BEFORE AUTH ROUTINE

• This routine is called during authorization of an INAU record.

• This routine is called before Auth Routine is executed.
EXAMPLE

There is a requirement, where in, while authorizing a customer

record, the user should be given the option to fill in any special
comments that he wishes to store along with the customer record
like “Special Customer” etc which can be used at a later date for
any special processing or could be printed along with the
statements sent to that particular customer. Therefore, write a
routine that will prompt the user to enter free text while authorizing
a customer record. Once the text is entered by the user, the data
needs to be updated in the field TEXT in the Customer application.
If no text is entered by the user then the message “No text entered.
Proceeding with other processing” should be displayed and the
record should get authorised.
• Create a subroutine that will prompt the user for the text and
update the TEXT field in the Customer application.
ALGORITHM

• Display a message to the user to input free text for a Customer

• Once the data is entered, update the Customer file
• Else display a message “No text entered. Proceeding with other
processing”
ROUTINE

SUBROUTINE BEFORE.AUTH.RTN
$INSERT GLOBUS.BP I_COMMON
$INSERT GLOBUS.BP I_EQUATE
$INSERT GLOBUS.BP I_F.CUSTOMER
Y.COLUMN = 8
Y.ROW = 22
N1 = 35.1
T1 = A
INP.MSG = 'Enter text for Customer'
CALL INP(INP.MSG,Y.COLUMN,Y.ROW,N1,T1)
IF COMI = '' THEN
CRT 'No text entered. Proceeding with other processing'
END
ELSE
R.NEW(EB.CUS.TEXT)<1,-1> = COMI
END
RETURN
END
ATTACHING THE ROUTINE

• EB.API ENTRY

• Attach the routine to the customer version

• Now try to input a customer and authorize it.

SUMMARY

• Input routine gets executed when a record is committed

• Auth routine gets executed when a record is authorized.
• After unauth routine is called after input routine.
• Before auth routine is execute, before auth routine executed.
• Common variables: COMI,R.NEW,ETEXT