Table of Contents

Phase 1:................................................................................................................................................ 4
$INSERT $INCLUDE..................................................................................................................... 4
GLOBUS.BP T24.BP..................................................................................................................... 4
OPEN CALL OPF........................................................................................................................... 4
READ  CALL F.READ:................................................................................................................... 5
READ/F.READ  CALL CACHE.READ:...........................................................................................7
READU  CALL F.READU:.............................................................................................................. 7
READV  CALL F.READV:.............................................................................................................. 9
MATREAD  F.MATREAD:............................................................................................................ 10
MATREADU  F.MATREADU:....................................................................................................... 11
CALL DBR  CALL F.READ:......................................................................................................... 11
WRITE  CALL F.WRITE:.............................................................................................................. 12
MATWRITE  CALL F.MATWRITE:............................................................................................... 13
DELETE  CALL F.DELETE:......................................................................................................... 13
RELEASE  CALL F.RELEASE:.................................................................................................... 14
HUSH ON/OFF................................................................................................................................ 14
DCOUNT......................................................................................................................................... 14
GET.LOC.REF  MULTI.GET.LOC.REF:.......................................................................................14
READNEXT  LOOP – REMOVE.................................................................................................. 16
EXECUTE/READLIST – PERFORM  CALL EB.READLIST:........................................................16
HARDCODED FIELDS SOFTCODED......................................................................................... 16
CALL REM DISPLAY.MESSAGE................................................................................................ 18
EXECUTE CALL.......................................................................................................................... 18
READSEQ:...................................................................................................................................... 18
CNAME  COPY............................................................................................................................ 19
FIX  DROUND.............................................................................................................................. 19
TIME ():............................................................................................................................................ 20
Phase 2:................................................................................................................................................ 21
OFS.GLOBUS.MANAGER.............................................................................................................. 21
OFS.CALL.BULK.MANAGER:......................................................................................................... 24
JOURNAL.UPDATE:........................................................................................................................ 24
Phase 3:.............................................................................................................................................. 26
OBSOLETE TABLES:...................................................................................................................... 26
1.1 F.DATES:....................................................................................................................... 26
1.2 CONSOL KEY TABLES................................................................................................. 26
1.3 POS.CON.SEC, POS.CON.DP, POS.CON.SCAC are made obsoletes........................31
1.4 DX.PRICE..................................................................................................................... 33
 1.5 ACCT.STMT.ENTRY / ACCT.STMT2.ENTRY:.............................................................34
1.6 CATEG.MONTH:.......................................................................................................... 35
1.7 RE.LD.ACC.BAL:.......................................................................................................... 35
1.8 RE.LMM.BALANCES:................................................................................................... 36
1.9 RE.MG.BALANCES:..................................................................................................... 37
1.10 ACCOUNT.DATE:.......................................................................................................... 39
1.11 POSITION.TABLE:......................................................................................................... 39
1.12 ACCT.ACCT.ACTIVITY:................................................................................................ 39
1.13 ACCT.ACTIVITY:........................................................................................................... 40
1.14 COLLATERAL AND COLLATERAL.RIGHT:..................................................................40
1.15 CHEQUES.PRESENTED AND CHEQUES.STOPPED:................................................40
1.16 SC.RATING:................................................................................................................. 41
1.17 DE.PHANTOM.RUN:..................................................................................................... 41
1.18 MD.EOD.LIST:............................................................................................................... 41
1.19 PM.POSN.REAL.TIME AND PM.POSN.VALUE.DATE:................................................41
1.20 DE.MM.O.END.OF.PERIOD & DE.MM.I.END.OF.PERIOD:..........................................42
1.21 POS.MVMT.LWORK.DAY:............................................................................................ 42
1.22 EB.COMPONENT:........................................................................................................ 42
1.23 HEDGE.FRA:................................................................................................................. 42
1.24 LIQ.TRADE:................................................................................................................... 42
1.25 LOCKED.BALANCE.AMT:............................................................................................. 42
1.26 MG.INTEREST.KEY & MG.RATE.FIX.DTE:..................................................................42
1.27 RE.CONSOL.FOREX, RE.CONSOL.LOAN, RE.CONSOL.LOAN.SEQU,
RE.CONSOL.MM, RE.CONSOL.MM.SEQU, RE.CONSOL.PD, RE.CONSOL.PD.SEQU,
RE.CONSOL.SEC:....................................................................................................................... 42
1.28 RE.CONTRACT.BALANCES:........................................................................................ 42
1.29 SA.PERMIUM.INTEREST.WRK & SA.PRM.INTEREST.WRK:.....................................43
1.30 SC.TRADING.POSITION:.............................................................................................. 43
1.31 ACCOUNT MACROS:.................................................................................................... 43
1.32 AZ.ACCOUNT.HIST:............................................................................................................ 45
1.33 RE.CONSOL.ACCT.HELD:.................................................................................................. 45
1.34 EB.SYSTEM.STATUS:......................................................................................................... 45
1.35 DRAW.SCHEDULES:.......................................................................................................... 45
OBSOLETE FIELDS:....................................................................................................................... 45
2.1 AC.CONSOL.KEY:......................................................................................................... 45
2.2 LD27.CONSOL.KEY...................................................................................................... 46
2.3 AC.ACCOUNT.CREDIT.INT -- AC.ACCT.CREDIT.INT:.............................................46
2.4 MAINTAIN.POS.TABLE field in REVAUATION.PARAMETER:.....................................47
2.5 TT.TE.NEW.CUST.BALANCE  TT.TE.NEW.CUST.BAL:...........................................47
2.6 FREQU.RELATIONSHIP  ACCOUNT.STATEMENT...............................................48
 2.7 AC.MKT.ACTUAL.BAL:.................................................................................................. 50
2.8 AC.PREV.OPEN.BAL:................................................................................................... 50
OBSOLETE Routines:..................................................................................................................... 52
RE.EXTRACT.ACCOUNT.NOS is obsolete from R07:................................................................52
RE.EXTRACT.LC.INFO is made obsolete:..................................................................................52
GM.CHK.HOLIDAY is made obsolete:......................................................................................... 52
SC.GET.SECURITY.POSITION.LIST:......................................................................................... 53
FWDRATES.REVAL:................................................................................................................... 53
DRAW.EOD.SCHEDULES:.......................................................................................................... 53
SPECIAL CASES:............................................................................................................................ 53
ACCT.ENT.TODAY...................................................................................................................... 53
CATEG.ENT.TODAY................................................................................................................... 54
CONSOL.ENT.TODAY................................................................................................................. 54
ACCOUNT.ACT........................................................................................................................... 55
AA.CONVERT.NEXT.ACTIVITY.................................................................................................. 55
AUTO NEW CONTENT:............................................................................................................... 55
ACCT.ENT.FWD :........................................................................................................................ 55
DE.MM.O.END.OF.PERIOD & DE.MM.I.END.OF.PERIOD:........................................................55
GET.CREDIT.CHECK:................................................................................................................. 55
AVAIL.FUNDS.UPDATE:............................................................................................................. 56
Annexure:........................................................................................................................................ 57
TAM.GET.LD.ECB.PRINCIPLE (CONTRACT.ID, LD.PR.AMT)...................................................57
TAM.GET.LD.ECB.ACCR.INT (CONTRACT.ID, LD.INT.AMT)....................................................57
TAM.MAT.INT.DATE.CHECK (MG.ID, MAT.DATE, NEXT.INT.DATE)........................................57
Phase 1:

$INSERT $INCLUDE

All $INSERT files present in the local codes have to be changed to $INCLUDE due to performance
constraint on compilation time as well as to make the code simple. As $INSERT will copy other BP’s
INSERT files into the local BP whereas $INLCUDE will read the insert files from their corresponding
BP and compile the code.

Reason for Change:

- To enhance the performance while compilation.

E.g.:

Before Change:

$INSERT I_F.CUSTOMER

After Change:

$INCLUDE T24.BP I_F.CUSTOMER

GLOBUS.BP T24.BP

All the local routines must include inserts from T24.BP and not from GLOBUS.BP. For existing
routines referring to GLOBUS.BP, change to T24.BP

E.g.:

Before Change:

$INCLUDE GLOBUS.BP I_F.CUSTOMER

After Change:

$INCLUDE T24.BP I_F.CUSTOMER

OPEN CALL OPF

As part of standardisation, OPEN statements used in lower release local codes for (opening jBASE
tables) will be replaced with T24 core routine OPF.

The following key points have to be followed for all code change on going.

- Only jBASE tables should be changed to core T24 routine OPF.

 - Ignore OPEN statements that are used for opening UNIX level directories if any.

Syntax for OPEN:

OPEN {expression1,} expression2 TO {variable} {SETTING sever} THEN|ELSE

statements

Syntax for OPF:

CALL OPF (Argument1, Argument2)

Where,

Argument1  The name of the Application to be opened, prefixed with an F.

Argument2  Output argument that contains the file path.

E.g.:

Before Change:

OPEN "F.COMPANY" TO F.COMPANY ELSE

ABORT 201, "COMPANY: Unable to OPEN"
END

After Change:

FN.COMPANY = ’F.COMPANY’
F.COMPANY = “”
CALL OPF (FN.COMPANY, F.COMPANY)

READ  CALL F.READ:

READ statements have to be converted to CALL F.READ as part of T24 coding standard
and in order to follow the transaction boundary.

The following key points have to be followed for all code change on going.

- Only jBASE tables should be converted to core T24 routine F.READ.

- UNIX level directories using READ should not be replaced with F.READ.

Syntax for READ:

The READ statement allows a program to read a record from a previously opened file
into a variable.

READ REC.ARRAY FROM FILE.VARIABLE, REC.ID THEN/ELSE condition

Syntax for F.READ:

CALL F.READ (FN.FILE, REC.ID, RECORD.VARIABLE, F.FILEPATH, FILE.ERR)

Incoming:

FN.FILE - File name 'F.xxxx.xxxxx’

REC.ID – Key
RECORD.VARIABLE – Record Buffer
F.FILEPATH – File Variable

Returned:
RECORD.VARIABLE – Data Record
FILE.ERR – Error Message

E.g.: The below scenarios are illustrated for your understanding.

Case1:
Before change:

READ record variable FROM FILE PATH, ID THEN

...statements....
END
After change:

CALL F.READ (FILE NAME, ID, Record variable, FILE path, ERR)
IF Record variable THEN
...statement....
END

Case2:

Before change:

READ record variable FROM FILE PATH, ID ELSE

....statements....
END

After change:

CALL F.READ (FILE NAME, ID, Record variable, FILE path, ERR)
IF ERR THEN
...statements....
END

Case3:

Before change:

READ record variable FROM FILE PATH, ID ELSE NULL

After change:
 CALL F.READ (FILE NAME, ID, Record variable, FILE path, ERR)

READ/F.READ  CALL CACHE.READ:

READ/F.READ made to parameter file should be replaced with CACHE.READ core routine.

The following key point has to be followed for all code change on going.

- If the record id in READ/F.READ is ‘SYSTEM’ then the replace READ/F.READ

to CACHE.READ.

Reason for Change:

- It reads from the temporary cache memory hence consume less time on doing
READ execution.

Syntax for F.READ:

CALL F.READ (FILE NAME, ‘SYSTEM’, Record variable, FILE path, ERR)

Syntax for CACHE.READ:

CALL CACHE.READ (FILE NAME, ‘SYSTEM’, Record variable, ERR)

NOTE:

When we change READ/F.READ TO CACHE.READ, CALL OPF should be removed

also ensure that CACHE.READ has only 4 arguments.
Also first parameter should be a actual file name.

E.g.:

Before change:

FN.TELLER.PARAMETER = ‘F.TELLER.PARAMETER’
F.TELLER.PARAMETER = ‘’
CALL OPF (FN.TELLER.PARAMETER, F.TELLER.PARAMETER)

CALL F.READ (FN.TELLER.PARAMETER, ID, R.REC, F.TELLER.PARAMETER, ERR)

After change:
FN.TELLER.PARAMETER = ‘F.TELLER.PARAMETER’

CALL CACHE.READ (FN.TELLER.PARAMETER,’SYSTEM’, R.REC, ERR)

Note: Analyse interdependencies and remove OPF

READU  CALL F.READU:

The READU statement allows a program to read a record from a previously opened file into
a variable. It respects record locking and locks the specified record for update.

Syntax for READU:

READU VARIABLE FROM FILE PATH, ID LOCKED IF/ELSE CONDITION

Syntax for F.READU:

CALL F.READU (FILE NAME, ID, RECORD VARIABLE, FILE PATH, ERR, RETRY)

Format of RETRY argument :

P Prompt the user with 'msg' if the record is locked. The default if 'msg' is null is 'xxxxx
msg FILE id RECORD LOCKED - RETRY Y/N'
R nn Retry xx times with a sleep interval of nn seconds. If xx is not specified the record is
xx continually retried
I Ignore the lock (REC or ARY is left as null)
E Return immediately with an error message
Null retry continuously with a sleep interval of one second.

E.g.: The below scenarios are illustrated for your understanding.

Case1:

Before change:

READU VARIABLE FROM FILE PATH, ID THEN

*** Statement ***
END

After Change:

CALL F.READU (FILE NAME, ID, RECORD VARIABLE, FILE PATH, ERR, RETRY)
IF ERR NE ‘’ THEN
*** statement ***
END

Case2:

Before change:

READU VARIABLE FROM FILE PATH, ID ELSE

*** Statement ***
END

After Change:
 CALL F.READU (FILE NAME, ID, RECORD VARIABLE, FILE PATH, ERR, RETRY)
IF ERR THEN
*** Statement ***
END

Case3:

Before change:

READU VARIABLE FROM FILE PATH,ID LOCKED

*** Locked Read***

*** Statement ***

END THEN

*****successful****

END ELSE
****Record does not exist****
END

After Change:

RETRY=’E’
CALL F.READU (FILENAME, ID, RECORDVARIABLE, FILE PATH, ERR, RETRY)

IF ERR EQ “Record Locked” THEN

*** Locked Read***

*** Statement ***
END ELSE

IF RECORDVARIABLE THEN
*****successful****
END ELSE

****Record does not exist****

END

END

READV  CALL F.READV:

The READV statement allows a program to read a specific field from a record in a previously
opened file into a variable.

Syntax for READV:

READV VARIABLE FROM FILEPATH, ID, FIELDNO THEN/ELSE CONDITION

Syntax for F.READV:

 CALL F.READV (FILENAME, ID, RECORD VARIABLE, FIELD NO, FILE PATH, ERR)

The following key points have to be followed for all code change on going.

- For all F.READ, F.READV, F.READU, OPF core routine should be used.
- Only jBASE tables should be converted to core T24 routine F.READV.

E.g.: The below scenarios are illustrated for your understanding.

Case1:

Before Change:

READV VARIABLE FROM FILEPATH, ID, FIELDNO THEN

After change:

CALL F.READV (FILENAME, ID, RECORD VARIABLE, FIELD NO, FILE PATH, ERR)

IF RECORD VARIABLE THEN

Case2:

Before Change:

READV VARIABLE FROM FILEPATH, ID, FIELDNO ELSE

After Change:

CALL F.READV (FILENAME, ID, RECORD VARIABLE, FIELD NO, FILE PATH, ERR)

IF ERR THEN

MATREAD  F.MATREAD:

The MATREAD statement allows a record stored in a jBASE file to be read and mapped
directly into a dimensioned array.

Syntax for MATREAD:

MATREAD ARRAY FROM FILENAME, ID IF/ELSE CONDITIONS

Syntax for F.MATREAD:

CALL F.MATREAD (FILENAME, ID, MAT ARRAY, ARRAY.SIZE, FILEPATH,

ERR)

Note: ARRAY.SIZE – Optional input. Default value NULL.

E.g.: The below scenarios are illustrated for your understanding.

ARRAY should be a previously defined dimensioned array

DIM ARRAY (SIZE)

Case1:

Before change:

MATREAD ARRAY FROM FILENAME, ID THEN

After Change:

CALL F.MATREAD (FILENAME, ID, MAT ARRAY, ARRAY.SIZE, FILEPATH, ERR)

IF ERR EQ ‘’ THEN

Case2:

Before change:

MATREAD ARRAY FROM FILENAME, ID ELSE

After Change:

CALL F.MATREAD (FILENAME, ID, MAT ARRAY, ARRAY.SIZE, FILEPATH, ERR)

IF ERR THEN

MATREADU  F.MATREADU:

The MATREADU statement allows a program to read a record from a previously opened file into a
dimensioned array. It respects record locking and locks the specified record for update

Syntax for MATREADU:

MATREADU ARRAY FROM FILENAME, ID IF/ELSE CONDITIONS

Syntax for F.MATREADU:

CALL F.MATREADU (FILENAME, ID, MAT ARRAY, ARRAY.SIZE, FILEPATH, ERR,

RETRY)

CALL DBR  CALL F.READ:

DBR is the T24 core routine which does the READ operation on any T24 table and fetches a
single field value. But as per coding standard, its better to avoid DBR and instead F.READ
should be used.

If multiple DBR’s reading same application with same @ID (record) then replace them with
single CALL F.READ.
Syntax for DBR:

CALL DBR (‘FILENAME’: FM:’FIELD NAME1’, REC_ID, FIELD.VALUE)

Syntax for F.READ:

CALL F.READ (FILE NAME, REC_ID, RECORD VARAIBLE, FILE PATH, ERR)
FIELD.VALUE = RECORD VARAIBLE<FIELD NAME1>

The following key points have to be followed for all code change ongoing.

- DBR doesn’t require CALL OPF.

- Hence while converting DBR to F.READ; CALL OPF for the table should be
inserted in the appropriate section.
- If only single DBR found in the routine, kindly ignore it, don’t change that code.

Reason for change:

- DBR executes OPF for each and every time to fetch the individual fields from the
same record hence to overcome this performance issue we opt F.READ to fetch
the same as it fetch the entire record in one single READ command.

E.g.:

Before Change:

CALL DBR (‘FILENAME’: FM:’FIELD NAME1’, ID, VARIABLE1)

CALL DBR (‘FILENAME’: FM:’FIELD NAME2’, ID, VARIABLE2)

After Change:

CALL F.READ (FILE NAME, ID, RECORD VARAIBLE, FILE PATH, ERR)
VARIABLE1 = RECORD VARAIBLE<FIELD NAME1>
VARIABLE2 = RECORD VARAIBLE<FIELD NAME2>

WRITE  CALL F.WRITE:

The WRITE statement allows a program to write a record into a previously opened file.

Syntax for WRITE:

WRITE VARIABLE ON FILENAME, ID

Syntax for F.WRITE:

CALL F.WRITE (FILENAME, ID, VARIABLE)

Reason for change:

In order to make the code T24 standard and to incorporate transaction boundary, WRITE
should be changed to CALL F.WRITE.

The following key points have to be followed for all code change on going.
 - WRITE directly hit the database while F.WRITE core routine updates in CACHE,
once JOURNAL.UPDATE routine called it will flush into database.
- Hence utmost care should be taken to deploy JOURNAL.UPDATE in the routine
once WRITE has been replaced with F.WRITE.
- JOURNAL.UPDATE shouldn’t be called in VERSION & BATCH routines as core
in turns will call the same.
- Only jBASE tables should be converted to core T24 routine F.WRITE
- UNIX level directories using WRITE should not be replaced with F.WRITE.

MATWRITE  CALL F.MATWRITE:

The MATWRITE statement transfers the entire contents of a dimensioned array to a

specified record on disc.

Syntax for MATWRITE:

MATWRITE ARRAY ON FILENAME, ID

Syntax for MATWRITE:

CALL F.MATWRITE (FILENAME, ID, MAT ARRAY, ARRAY.SIZE)

 ARRAY.SIZE – Optional input. Default value NULL.

 ARRAY should be a previously defined dimensioned array

DIM ARRAY.NAME (SIZE)

Reason for change:

In order to make the code T24 standard and to incorporate transaction boundary,
MATWRITE should be changed to F.MATWRITE.

The following key points have to be followed for all code change ongoing.

- MATWRITE directly hit the database while F.MATWRITE core routine updates in
CACHE, once JOURNAL.UPDATE routine called it will flush into database.
- Hence utmost care should be taken to deploy JOURNAL.UPDATE in the routine
once MATWRITE has been replaced with F.MATWRITE.
- JOURNAL.UPDATE shouldn’t be called in VERSION & BATCH routines as core
in turns will call the same.

DELETE  CALL F.DELETE:

The DELETE statement will delete a record from a jBASE file.

Syntax for DELETE:

DELETE FILEPATH, ID

Syntax for F.DELETE:

CALL F.DELETE (FILENAME, ID)

Note:
This API F.DELETE should be followed by JOURNAL.UPDATE to flush the updated
(deleted) record into disk. JOURNAL.UPDATE should not be called only if the routine is a
VERSION routine or BATCH routine.

RELEASE  CALL F.RELEASE:

The RELEASE statement enables a program to explicitly release record locks without
updating the records using WRITE.

Syntax for RELEASE:

RELEASE FILENAME, ID

Syntax for F.RELEASE:

CALL F.RELEASE (FN.FILENAME, ID, F.FILENAME)

HUSH ON/OFF

HUSH statement is used to suppress the display of all the output sent to a terminal during
processing. It also suppresses output to a COMO file. It acts as a toggle.

HUSH ON suppresses all output including error messages and requests for information.

HUSH {ON/OFF/exp}

Reason to Remove:

HUSH OFF/ON should be analysed and should be removed if they are used in BATCH
or/Mainline routines

DCOUNT

The DCOUNT () function counts the number of field elements in a string that are separated
by a specified delimiter.

DCOUNT (exp1, exp2)

Where exp1evaluates to a string in which fields are to be counted.

exp2evaluates to the delimiter string used to count the fields.

FOR I=1 TO DCOUNT (exp1, exp2)


CNT = DCOUNT (exp1, exp2)
FOR I=1 TO CNT

Note: The above change has to be done to avoid inline coding.

GET.LOC.REF  MULTI.GET.LOC.REF:
GET.LOC.REF core routine is used to read the position of local reference fields in any
application through STANDARD.SELECTION record.

Reason for change:

To enhance the performance of the coding, multiple GET.LOC.REF routine present in the
routine should be replaced with a single call to MULTI.GET.LOC.REF.

Note:
The following key points have to be followed for all code change on going.

- If the two fields belong to same application, second argument YFIELD.NAME

should be separated by ‘VM’.

- If the two fields belong to different application, second argument YFIELD.NAME

should be separated by ‘FM’.

E.g.: The below scenarios are illustrated for your understanding.

Before Change:

CALL GET.LOC.REF (APPLICATION1, FIELD.NAME1, FIELDPOS1)

CALL GET.LOC.REF (APPLICATION2, FIELD.NAME2, FIELDPOS2)
CALL GET.LOC.REF (APPLICATION2, FIELD.NAME3, FIELDPOS3)

OR
CALL EB.GET.LOC.POS (FIELDPOS1, APPLICATION1, FIELD.NAME1)
CALL EB.GET.LOC.POS (FIELDPOS2, APPLICATION2, FIELD.NAME2)
CALL EB.GET.LOC.POS (FIELDPOS3, APPLICATION2, FIELD.NAME3)

After change:

YAPPLICATION.NAME=’’
YFIELD.NAME =’’

YAPPLICATION.NAME = “APPLICATION1”:FM:“APPLICATION2”
YFIELD.NAME =“FIELD NAME1”:FM:“FIELD NAME2”:VM:” FIELD NAME3”

LREF.POS = ‘’

CALL MULTI.GET.LOC.REF (YAPPLICATION.NAME, YFIELD.NAME, LREF.POS)

FIELDPOS1 = LREF.POS<1, 1>

FIELDPOS2 = LREF.POS<2, 1>
FIELDPOS3 = LREF.POS<2, 2>

OR

YAPPLICATION.NAME<1>=’’
YAPPLICATION.NAME<2>=’’

YFIELD.NAME<1,1> =’’
YFIELD.NAME<2,1> =’’
YFIELD.NAME<2,2> =’’

LREF.POS = ‘’

CALL MULTI.GET.LOC.REF (YAPPLICATION.NAME, YFIELD.NAME, LREF.POS)

 FIELDPOS1 = LREF.POS<1, 1>
FIELDPOS2 = LREF.POS<2, 1>
FIELDPOS3 = LREF.POS<2, 2>

READNEXT  LOOP – REMOVE

READNEXT retrieves the next element in a list variable. But in order to standardise the
codes, READNEXT should be replaced with LOOP – REMOVE fashion.

Syntax for READNEXT:

READNEXT ID FROM VARIABLE SETTING POS ELSE CONDITION

Syntax for LOOP-REMOVE:

LOOP
REMOVE ID FROM VARIABLE SETTING POS
WHILE ID: POS
…………
…………

REPEAT

EXECUTE/READLIST – PERFORM  CALL EB.READLIST:

The EXECUTE or PERFORM statement allows the currently executing program to pause
and execute any other UNIX/NT program, including another jBC program or a jBASE
command.
READLIST allows the program to retrieve a previously stored list (Perhaps created with the
SAVE-LIST command) into a jBC variable.

E.g.: The below scenario are illustrated for your understanding.

Before Change:

EXECUTE “SELECT “:FN.CUSTOMER

READLIST SEL.LIST THEN/ELSE CONDITION

After Change:

SELCMD = ‘SELECT “:FN.CUSTOMER

CALL EB.READLIST (SELCMD, SEL.LIST,’ ‘, NO.OF.RECS, SEL.ERR)

HARDCODED FIELDS SOFTCODED

Reason for change:

No local codes should be HARDCODED as it might cause the system to fail if any upgrade
or on service pack installation has been done. To overcome this issue, hardcoded fields
should be soft coded.

E.g.: The below scenarios are illustrated for your understanding.

Case 1:

Before Change:

CALL F.READ (FN.ACC, Y.ID, R.REC, F.ACC, ERR)

IF R.REC THEN
CUS.NO = R.REC<1>
END

After Change:

$INCLUDE GLOBUS.BP I_F.CUSTOMER

CALL F.READ (FN.ACC, Y.ID, R.REC, F.ACC, ERR)

IF R.REC THEN
CUS.NO = R.REC<AC.CUSTOMER>
END

Note: -
The above hardcoded array variable R.REC<1> has to be soft coded with the
corresponding INSERT field name as above.

Case 2:

Incase if the hardcoded fields are local ref fields then GET.LOC.REF core routine
has to be used.

Before Change:

R.CUSTOMER<40,2> = ‘IEX’

After Change:

$INCLUDE GLOBUS.BP I_F.CUSTOMER

FIELD.POS = ‘’
CALL GET.LOC.REF (‘CUSTOMER’,’TAX.STATUS’, FIELD.POS)
R.CUSTOMER<EB.CUS.LOCAL.REF, FIELD.POS> = ‘IEX’

Note: -
The hardcoded field no: 40 has been replaced with the corresponding INSERT file
field name I_F.CUSTOMER and the hard coded local ref field has been replaced with the
soft coded field name ‘TAX.STATUS’ through GET.LOC.REF core routine.

Case 3: Hard code in F.READV functions.

Before Change:

CALL F.READV (FN.ACCOUNT, AC.ID, R.ACC, 2, F.ACCOUNT, ERR.A)

After Change:

$INCLUDE GLOBUS.BP I_F.ACCOUNT

CALL F.READV (FN.ACCOUNT, AC.ID, R.ACC, AC.CATEGORY, F.ACCOUNT, ERR.A)

Note:
Hardcoded number ‘2’ should be replaced with the corresponding
STANDARD.SELECTION field no. that has been defined in the INSERT file I_F.ACCOUNT.

CALL REM DISPLAY.MESSAGE

Call to REM will not work in BROWSER. So if the code is converted for BROWSER then
REM should be replaced with a call to DISPLAY.MESSAGE

E.g.:

Before Change:
IF ID.NEW NE 'SYSTEM' THEN
TEXT = 'ID MUST BE SYSTEM'
CALL REM
END

After Change:
IF ID.NEW NE 'SYSTEM' THEN
TEXT = 'ID MUST BE SYSTEM'
CALL DISPLAY.MESSAGE (TEXT,'')
END

EXECUTE CALL

In G13 EXECUTE statement allows the currently executing program to pause and execute other
subroutine or program mentioned. Same Functionality doesn’t exist in R10 hence CALL Function has
to be used instead.

E.g.:

Before change:

EXEC ROUTINE.NAME
After change:

PROGR = ROUTINE.NAME
CALL @PROGR

READSEQ:

To avoid the infinite LOOP, a FILEPOINTER has to be set up in the READSEQ statement.
Before change:

LOOP
READSEQ F.LINE FROM F.IN THEN
GOSUB READ.LMM.DATA
END
UNTIL F.LINE = ""
REPEAT
After change:
LOOP
READSEQ F.LINE FROM F.IN SETTING FILEPOINTER THEN
GOSUB READ.LMM.DATA
END
UNTIL FILEPOINTER NE ''
REPEAT

CNAME  COPY

CNAME Function used to change the name of a file or to change the names of record in a file and it is
unavailable in R10; hence the local routine using CNAME must be modified to use COPY command.

Before change:

CNAME.CMD="CNAME ":IN.DIRECTORY:" ":FILE.NAME:", ":FILE.NAME:"-":XX

After change:
CNAME.CMD="COPY FROM ":IN.DIRECTORY:" ":FILE.NAME:",":FILE.NAME:"-":XX:"
OVERWRITING “

FIX  DROUND

FIX Command is used in Universe, DROUND should be used instead of FIX in TAFC.

Before change:

CRT FIX (1.2345678, 5)

will display the value 1.23457

After change:

CRT DROUND (1.23456)

will display the value 1.2346 (using the default precision of 4)
CRT DROUND (1.2345678, 5)
will display the value 1.23457

TIME ():

In G13 TIME Function returns the string value expressing the internal time of the day, which is the
number of seconds that have passed since midnight to the nearest thousandth of the second (local
time).

Note:
This functionality change should be considered when using the function TIME ().

Before change:

TIME.TEST=TIME ()

Output:
25288.8121

After change:
TIME.TEST = TIME ()

Output:
25320
Phase 2:
This phase provides adequate information about the handling of OFS.GLOBUS.MANAGER core
routine in Version/Batch applications and handling of JOURNAL.UPDATE in local routines.

OFS.GLOBUS.MANAGER
Using OFS.GLOBUS.MANAGER from R07 in the Version application leads to Sensitive Routine
Called Fatal out. To make the local code R07/R08 compliance, we have to change the code
correspondingly as mentioned below cases.
Before going into the cases, find below the few core routine syntax:
Syntax:
CALL OFS.GLOBUS.MANAGER (OFS.SOURCE.ID, OFS.MSG)
Incoming Arguments:
OFS.SOURCE.ID = OFS.SOURCE record @id.
OFS.MSG = OFS message String to be processed.
Outgoing Arguments:
OFS.MSG = OFS message with Processed Status (1/ -1)
CALL OFS.POST.MESSAGE (OFS.MSG, QUE.MSG.ID, OFS.SOURCE.ID, OPTIONS)
Incoming Arguments:
OFS.SOURCE.ID = OFS.SOURCE record @id.
OFS.MSG = OFS message String to be processed.
QUE.MSG.ID = OFS.MESSAGE.QUEUE record ID (Optional)
OPTIONS = Optional, Default value will be Null.

CALL OFS.PROCESS.MANAGER (OFS.MSG.IN, OFS.MSG.OUT)

Incoming Argument:
OFS.MSG.IN = OFS message String to be processed.
Outgoing Argument:
OFS.MSG.OUT = OFS message with Processed Status (1/ -1)
OFS.PROCESS.MANAGER THIS WILL ADD IN QUEUE AND THEN REQUEST MANAGER
WILL PROCESS IT.

CASE 1: FOR VERSION AND MULTI-THREADED ROUTINES

1. Add/Replace the OFS message string value: VALIDATE instead of PROCESS.

2. If output response EQ 1, then CALL OFS.POST.MESSAGE.

For Example, consider the below scenario,

Before Change:
T24.ERR = ''
 OFS.STR = “ABBREVIATION, //PROCESS, TEST.USER/654321, SEC,
ORIGINAL.TEXT=SECTOR“
CALL OFS.GLOBUS.MANAGER (OFS.SOURCE.ID, OFS.STR)
CHKVAL = FIELD (OFS.STR,'/',3)
IF CHKVAL [1, 1] = 1 ELSE
T24.ERR = 'SET'
END

Replace the OFS.STR value PROCESS to VALIDATE and pass the same in
OFS.GLOBUS.MANAGER. While changing here we have to be careful since some routines might not
have the OFS string formation in the same routine. Here we are using EREPLACE to replace
PROCESS to VALIDATE ,while doing this be sure about the syntax of EREPLACE and note down the
message variable passed in OFS.GLOBUS.MANAGER,

After Change:
OFS.STR.TEMP = OFS.STR
OFS.STR.TEMP = EREPLACE (OFS.STR,'PROCESS','VALIDATE', 1, 1)
CALL OFS.GLOBUS.MANAGER (OFS.SOURCE.ID, OFS.STR.TEMP)
CHKVAL = FIELD (OFS.STR.TEMP,'/', 3)

If the response is success (+1), then call the OFS.POST.MESSAGE as mentioned below;
check the IF condition carefully.

IF CHKVAL [1, 1] = 1 THEN

CALL OFS.POST.MESSAGE (OFS.STR,'', OFS.SOURCE.ID,'')      
END 1 ELSE
T24.ERR = 'SET'
END

Note:
Before converting OFS.GLOBUS.MANAGER to OFS.POST.MESSAGE Analyse the routine
fully for the usage of Return message from OFS.GLOBUS.MANAGER since they may use the id from
the response for other purposes.

CASE 2: BATCH – SINGLE THREAD ROUTINE

1. Remove the CALL OFS.GLOBUS.MANAGER code.

2. Read the OFS.SOURCE record and assign the @ID to OFS$SOURCE.ID & OFS.SOURCE
record content to OFS$SOURCE.REC Common Variable.
3. Now Call OFS.PROCESS.MANAGER.
4. Include I_GTS.COMMON file in the insertion part.

Before Change:
T24.ERR = ''
CALL OFS.GLOBUS.MANAGER (OFS.SOURCE.ID, OFS.STR)
CHKVAL = FIELD (OFS.STR, '/', 3)
IF CHKVAL [1, 1] = 1 ELSE
T24.ERR = 'SET'
END

After Change:
$INSERT I_GTS.COMMON

T24.ERR = ''
OFS$SOURCE.ID = OFS.SOURCE.ID
CALL F.READ (FN.OFS.SOURCE, OFS.SOURCE.ID, R.OFS, F.OFS.SOURCE, OF.ERR)
OFS$SOURCE.REC = R.OFS ;* imp
CALL OFS.PROCESS.MANAGER (OFS.STR, OFS.STR.OUT)
OFS.STR = OFS.STR.OUT ;* imp
CHKVAL = FIELD (OFS.STR,'/',3)
IF CHKVAL [1,1] = 1 ELSE
T24.ERR = 'SET'
END

Special Case:
*A call to EB.TRANS is done to ensure that the transaction boundary thus far active within the tSA is
closed. This is done by checking the SYSTEM common variable to ensure that the transaction
boundary is closed only if there is an active transaction boundary in effect. This process is done to
ensure that the transaction boundaries do not clash with the OFS update that will be attempted
subsequently.
IF SYSTEM (47) THEN
CALL EB.TRANS ('END', R.MSG)
END
* Invoke OFS Process Manager by passing the following arguments
* Argument 1 --> OFS Message that is to used to update the application
* Argument 2 --> OFS Message that is returned as a response

CALL OFS.PROCESS.MANAGER (OFS.MSG.IN, OFS.MSG.OUT)

* NOTE: OFS.PROCESS.MANAGER and not OFS.POST.MESSAGE is used since this
interface requires that the response from the OFS processing is to be updated into the tracking table.
By using OFS.POST.MESSAGE this is not possible since OFS.POST.MESSAGE hands the actual
update over to the OFS.MESSENGER.SERVICE that is an asynchronous process. This interface
cannot delay subsequent message processing to poll the OFS response queues of the
OFS.MESSENGER.SERVICE to determine the status of the OFS update request passed.

* Open a new transaction boundary after the OFS update has been completed this will ensure
that the subsequent updates are properly catered for and will also ensure that the transaction
boundary close attempted by the tSA does not fail.
IF NOT (SYSTEM (47)) THEN
CALL EB.TRANS ('START', R.MSG)
END

CASE 3: MAINLINE ROUTINE:

If OGM is called in any routine with PGM.FILE type as “M”, make sure the cache is empty
before calling OGM
1. There should not be any CALL to F.DELETE, F.WRITE /WRITE to any file before OGM.
2. If any call is made to the above API then it should be flushed to the database before calling
OGM using a JOURNAL.UPDATE routine.

OFS.CALL.BULK.MANAGER:

Upto R08, the syntax of OFS.CALL.BULK.MANAGER will have only three arguments. But in
higher release it will throw SUB_ROUTINE_PARAM error, because from R09 onwards the syntax of
OFS.CALL.BULK.MANAGER is modified with 4 arguments.
Syntax:
CALL OFS.CALL.BULK.MANAGER (options, theRequest, theResponse)
To make the code compliance to higher release the syntax should be altered as like given
below.
Syntax:
CALL OFS.CALL.BULK.MANAGER (options, theRequest, theResponse, txnCommitted)

Arguments
Options -
<1> sourceId the OFS SOURCE record to use
<2> error options
<3> append or Insert, default is append only used for OBM
theRequest - the OFS message request to process
theResponse (return parameter) - Responses from messages
txnCommitted (return parameter) - set to true if the transaction is committed

JOURNAL.UPDATE:

In Phase 1 Activities, we have changed all the jBASE WRITE comment into CALL F.WRITE. Since
WRITE will directly update the data into Database. We don’t need to call JOURNAL.UPDATE earlier
but core routine F.WRITE will write the data into a Temporary cache, which mean that to hit the
database we need to CALL JOURNAL.UPDATE.
Syntax:
CALL JOURNAL.UPDATE (‘’)
Steps To Do:
Analyze the Code and change as mentioned below.
1. Remove the JOURNAL.UPDATE if they used in any COB routines. i.e., If PGM.FILE type is
‘B’ then do the above said because core in turns call the JOURNAL.UPDATE routine.
2. If it’s a Mainline Program i.e., If PGM.FILE type is M, then CALL JOURNAL.UPDATE should
be included in the routine.
3. In Version either Input/Auth routine, if CALL JOURNAL.UPDATE has been used then
remove the same from the routine.
4. For Enquiry routines if any CALL F.WRITE attempt made, then include CALL
JOURNAL.UPDATE in the routine.
5. For EB.PHANTOM related routines, CALL JOURNAL.UPDATE should be used in case of any
update done to cache.
6. For OFS.SOURCE related routines CALL JOURNAL.UPDATE shouldn’t be used.
7. Calls to Multiple JOURNAL.UPDATEs should be avoided inside the same routine deeming
performance issue. For Example if CALL JOURNAL.UPDATE is given inside the loop or
inside each sub function then remove it and place it in the end of the routine.
NOTE:
If any CALL F.WRITE is made before CALL OFS.GLOBUS.MANAGER then we need to
include CALL JOURNAL.UPDATE before CALL OFS.GLOBUS.MANAGER, else it will FATAL
OUT, since the cache should be empty before calling OFS.GLOBUS.MANAGER.

Phase 3:
OBSOLETE TABLES:
1.1 F.DATES:

In local routines, CALL OPF for DATES application has to avoid as we have F.DATES common
variable defined in I_COMMON. Similarly CALL F.READ should be avoided as R.DATES
dimensioned common variable already defined in I_COMMON file.
Consider the below example.
Note:
While changing the code analyse and then change the code because they could have done
READ for ID.COMPANY-COB record, we shouldn’t unnecessarily change the program logic blindly.

Before Change:
FN.DATES = ‘F.DATES’
F.DATES = ‘’
CALL OPF (FN.DATES, F.DATES)
CALL F.READ (FN.DATES, ID.COMPANY, R.DAT.COMP, F.DATES, DAT.ERR)
YTODAY = R.DAT.COMP<EB.DAT.TODAY>
YLAST.DAY = R.DAT.COMP<EB.DAT.LAST.WORKING.DAY>
After Change:
YTODAY = TODAY ;* TODAY Common Variable
YLAST.DAY = R.DATES (EB.DAT.LAST.WORKING.DAY) ;* R.DATES common dim var

Note:
The following INSERT files should be MANDATORY in the local routine to incorporate the
above changes.
$INCLUDE GLOBUS.BP I_COMMON
$INCLUDE GLOBUS.BP I_F.DATES

1.2 CONSOL KEY TABLES

The following tables was made obsolete from R07 itself.
 RE.CONSOL.ACCCOUNT
 RE.CONSOL.LOAN
 RE.CONSOL.LOAN.SEQU
 RE.CONSOL.MM
 RE.CONSOL.MM.SEQU
 RE.CONSOL.PD
 RE.CONSOL.PD.SEQU
 RE.CONSOL.SEC
 RE.CONSOL.FOREX

The reason behind is to have all the product related Consol keys in a central repository file.
The replacement for the above table is RE.CONSOL.CONTRACT.
RE.CONSOL.LOAN:

The “RE.CONSOL.LOAN” is the file in G14 release which maintains the Consol Key entry for
Loans. Likewise separate files are maintained for MM, FOREX, and AC, etc.
From R07 these CONCAT tables are made OBSOLETE so instead we will be using the central
repository file “RE.CONSOL.CONTRACT”. Find below the sample screenshot of the same.

CASE 1:
  Change the READ for RE.CONSOL.ACCCOUNT, RE.CONSOL.LOAN, etc to
RE.CONSOL.CONTRACT. But the id should be same.
 Also perform OPF for RE.CONSOL.CONTRACT and remove CALL OPF for
RE.CONSOL.ACCOUNT, RE.CONSOL.LOAN.
 Don’t change the Record variable(e.g.: R.RE.CONSOL.ACCOUNT)

Before Change:

FN.RE.CONSOL.ACCOUNT = ‘F.RE.CONSOL.ACCOUNT’
F.RE.CONSOL.ACCOUNT = ‘’
CALL OPF (FN.RE.CONSOL.ACCOUNT, F.RE.CONSOL.ACCOUNT)

CALL F.READ (FN.RE.CONSOL.ACCOUNT, YCONSOL.KEY, R.RE.CONSOL.ACCOUNT,

F.RE.CONSOL.ACCOUNT, CONACC.ERR)

After Change:
FN.RE.CONSOL.CONTRACT = ‘F.RE.CONSOL.CONTRACT’
F.RE.CONSOL.CONTRACT = ‘’
CALL OPF (FN.RE.CONSOL.CONTRACT, F.RE.CONSOL.CONTRACT)

CALL F.READ (FN.RE.CONSOL.CONTRACT, YCONSOL.KEY, R.RE.CONSOL.ACCOUNT,

F.RE.CONSOL.CONTRACT, CONACC.ERR)

CASE 2: SELECT Scenarios.

 In case select happen in the files RE.CONSOL.ACCOUNT, RE.CONSOL.LOAN, etc.

Example 1:
Before Change
SEL.CMD=”SELECT F.RE.CONSOL.ACCOUNT”

After Change
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE AC...”

 Because the RE.CONSOL.ACCOUNT is related to only for product account. So we

have to retrieve using select on account related records from
RE.CONSOL.CONTRACT.
  Similarly for other RE.CONSOL.XXX files have to be done as mentioned below.

Before Change
SEL.CMD=”SELECT F.RE.CONSOL.LOAN”
After Change
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE LD...”

Before Change
SEL.CMD=”SELECT F.RE.CONSOL.SEC”
After Change
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE SC...”

Before Change
SEL.CMD=”SELECT F.RE.CONSOL.MM”
After Change
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE MM...”

Before Change
SEL.CMD=”SELECT F.RE.CONSOL.PD”
After Change
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE PD...”

Before Change
SEL.CMD=”SELECT F.RE.CONSOL.FOREX”
After Change
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE FX...”

Example 2:

Before Change
SEL.CMD=”SELECT F.RE.CONSOL.ACCOUNT WITH @ID LIKE 6001”
SEL.CMD=”SELECT F.RE.CONSOL.ACCOUNT WITH @ID LIKE USD”
After Change:
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE AC...6001...”
SEL.CMD=”SELECT F.RE.CONSOL.CONTRACT WITH @ID LIKE AC...USD...”
 If you see other then the files specified below doesn’t change it instead you have to
report/escalate the issue with seniors.

 RE.CONSOL.ACCCOUNT
 RE.CONSOL.LOAN
 RE.CONSOL.LOAN.SEQU
 RE.CONSOL.MM
 RE.CONSOL.MM.SEQU
 RE.CONSOL.PD
 RE.CONSOL.PD.SEQU
 RE.CONSOL.SEC
 RE.CONSOL.FOREX

1.3 POS.CON.SEC, POS.CON.DP, POS.CON.SCAC are made obsoletes.

The Local routines making use of these back end files POS.CON.DP and POS.CON.SEC are made
obsolete from R07 release and POS.CON.SCAC is made obsolete from R08 release. Hence to make
the local routines R08 compliance we have to use DAS concept.
Go through the below syntax and the uses of DAS concept.

SYNTAX:
CALL DAS (APP.NAME, RETURNLIST, THE.ARGS, TABLE.SUFFIX)
The core routine DAS has to be used in all places earlier where POS.CON.DP, POS.CON.SEC and
POS.CON.SCAC are used. DAS routine has 4 incoming arguments and 1 outgoing argument, they
are

INCOMING ARGUMENT:
APP.NAME:
This argument uses the respective application name to retrieve the list.
Ex:
APP.NAME = 'SECURITY.POSITION'

RETURNLIST

This argument has to be passed with Query name that has been defined in the corresponding
Common File GLOBUS.BP> I_DAS.SECURITY.POSITION.NOTES and
I_DAS.SECURITY.POSITION
 If POS.CON.SEC list needed use the below query else if you need POS.CON.DP LIST use
latter one.
Sample query name is mentioned below, these will be changed based on the routine logic.

RETURNLIST = dasSecurityPositionCustomerSecurity,
DasSecurityPositionCustomerDepository.

THE.ARGS
This argument has to input in array format delimited by FM.

For example:

THE.ARGS = ID.COMPANY
THE.ARGS<2> = ‘Input either Depository no or Security master no’

TABLE.SUFFIX:

Indicate which file has to use either NAU or HIS type. If null specified, then live file will be
selected.
TABLE.SUFFIX = $HIS or $NAU or null value.

OUTGOING ARGUMENT:
RETURNLIST: The extracted output list will present this argument.
Change all the below routines as mentioned above DAS concept.

Find below few test cases:

I) POS.CON.SEC:
Replace the before change code with the code block specified in the after Change
section.

Before Change:
Remove the following line of code:
CALL F.READ (FN.POS.CON.SEC, SM.ID, R.POS.CON.SEC, F.POS.CON.SEC, RE.ERR)
After Change:

Add the following lines of code:

 R.POS.CON.SEC = dasSecurityPositionCustomerSecurity
THE.ARGS = ID.COMPANY
THE.ARGS<2> = SM.ID
TABLE.SUFFIX = ''
CALL DAS ('SECURITY.POSITION', R.POS.CON.SEC, THE.ARGS, TABLE.SUFFIX)

Note: Don’t forget to add the below Insert files in the changed routines.
$INCLUDE GLOBUS.BP I_DAS.COMMON
$INCLUDE GLOBUS.BP I_DAS.SECURITY.POSITION

II) POS.CON.DP:
Replace the before change code with the code block specified in the after Change section.

Before Change:
CALL F.READ ('F.POS.CON.DP', K.DEPO, R.POSDP, F.POSDP, RE.ERR1)
After Change:
R.POSDP = dasSecurityPositionCustomerDepository
THE.ARGS = ID.COMPANY
THE.ARGS<2> = K.DEPO
TABLE.SUFFIX = ''
CALL DAS ('SECURITY.POSITION', R.POSDP, THE.ARGS, TABLE.SUFFIX)

Note: Don’t forget to add the below Insert files in the changed routines.
$INCLUDE GLOBUS.BP I_DAS.COMMON
$INCLUDE GLOBUS.BP I_DAS.SECURITY.POSITION

III) POS.CON.SCAC:
Replace the before change code with the code block specified in the after Change section.

Before Change:

FN.POS.CON.SCAC = ‘F.POS.CON.SCAC’
F.POS.CON.SCAC = ‘’
CALL OPF (FN.POS.CON.SCAC, F.POS.CON.SCAC)
CALL F.READ (FN.POS.CON.SCAC, K.SCAC, R.POS.CON.SCAC, F.POS.CON.SCAC,
RE.ERR2)

After Change:
 R.POS.CON.SCAC = dasSecurityPositionSecurityAccount
THE.ARGS = K.SCAC
TABLE.SUFFIX = ''
CALL DAS ('SECURITY.POSITION', R.POS.CON.SCAC, THE.ARGS, TABLE.SUFFIX)

Note: Don’t forget to add the below Insert files in the changed routines.
$INCLUDE GLOBUS.BP I_DAS.COMMON
$INCLUDE GLOBUS.BP I_DAS.SECURITY.POSITION

1.4 DX.PRICE

DX.PRICE application was made obsolete and henceforth all local routines using DX.PRICE
have to be replaced with DX.MARKET.PRICE application and the corresponding fields have to be
mapped as per the new setup.

1.5 ACCT.STMT.ENTRY / ACCT.STMT2.ENTRY:

ACCT.STMT.ENTRY/ACCT.STMT2.ENTRY tables were made obsolete from R07 release as

STMT.PRINTED will be updated online itself. So any local routines using this table have to be
switched over to STMT.PRINTED. To implement the same, the following logic has to be followed.

CASE 1:
If CALL F.READ used for ACCT.STMT.ENTRY/ ACCT.STMT2.ENTRY, then follow
the below,
1. Read ACCOUNT.STATEMENT application for the corresponding account record.
2. Retrieve either any one of the field STMT.FQU.1 or STMT.FQU.2 based on the table
used. i.e., if ACCT.STMT.ENTRY has been read, then STMT.FQU.1 has to be retrieved
else if ACCT.STMT2.ENTRY has been used then STMT.FQU.2 has to be retrieved.
3. Concatenate the retrieved Frequency value with the ACCOUNT @id as mentioned below.
STMT.PRINTED.ID = ACCOUNT.ID:’-‘:STMT.FQU.1
Or
STMT.PRINTED.ID = ACCOUNT.ID:’-‘:STMT.FQU.2
4. Read STMT.PRINTED using the above @ID, and extract the current month stmt.entries
as mentioned below example.

Before Change:
READ R.ACCT.STMT.ENTRY FROM F.ACCT.STMT.ENTRY, ACCOUNT THEN
STMT.ENTRIES = R.ACCT.STMT.ENTRY
END
 After Change:
READ R.ACC.STMT FROM F.ACCOUNT.STATEMENT, ACCOUNT THEN
STMT.FREQ = R.ACC.STMT<AC.STA.STMT.FQU.1>
END

STMT.PRINTED.ID = ACCOUNT:’-‘:STMT.FREQ[1,8]
READ R.STMT.PRI FROM F.STMT.PRINTED, STMT.PRINTED.ID THEN
STMT.ENTRIES = R.STMT.PRI
END

Note: Incase if CALL F.READ is used for the above ex, then change the logic accordingly. Also
corresponding Insert files if any and CALL OPF have to be incorporated.

1.6 CATEG.MONTH:

The above table made was obsolete instead CATEG.ENT.MONTH and

CATEG.ENT.ACTIVITY are two replacement tables having categ entries monthly wise for all
categories.
In order to make local code as R08 compliance, the following logic has to be built in order to
get CATEG.ENTRIES id.
Ex:

Before Change:
CALL F.READ (FN.CATEG.MONTH,’ 53012.200303’, R.CATEG.MONTH,
F.CATEG.MONTH, CE.ERR)

After Change:
START.DATE = 20030301
END.DATE = 20070330
CATEGORY = 53012
R.CATEG.MONTH = ''
CALL GET.CATEG.MONTH.ENTRIES (START.DATE, END.DATE, CATEGORY,
R.CATEG.MONTH)

1.7 RE.LD.ACC.BAL:
The table RE.LD.ACC.BAL was made obsolete from R07 instead a single point for all
Contract balances created as EB.CONTRACT.BALANCES.
However in the below cases, we have depicted only for few important fields and
there corresponding R08 compliance fields in LMM.ACCOUNT.BALANCES.
 Before Change:

$INCLUDE GLOBUS.BP I_F.RE.LD.ACC.BAL

FN.RE.LD.ACC.BAL = 'F.RE.LD.ACC.BAL'
F.RE.LD.ACC.BAL = ''
CALL OPF (FN.RE.LD.ACC.BAL, F.RE.LD.ACC.BAL)

CALL F.READ (FN.RE.LD.ACC.BAL, Y.CNTR.ID, R.RE.LD.ACC.BAL, F.RE.LD.ACC.BAL,

LDERR)

YR.AMT.BAL = R.RE.LD.ACC.BAL<RE.LAB.OUTS.CURR.PRINC>
Y.CURR = R.RE.LD.ACC.BAL < RE.LAB.CURRENCY>

The above core fields have to be replaced to make the local routine compatible with R08.

After Change:

$INCLUDE GLOBUS.BP I_F.LMM.ACCOUNT.BALANCES

FN.LMM.ACCOUNT.BALANCES = ‘F.LMM.ACCOUNT.BALANCES
F.LMM.ACCOUNT.BALANCES = ‘’
CALL OPF (FN.LMM.ACCOUNT.BALANCES, F.LMM.ACCOUNT.BALANCES)

CALL F.READ (FN.LMM.ACCOUNT.BALANCES, Y.CNTR.ID, R.LMM.BAL,

F.LMM.ACCOUNT.BALANCES, LMMBAL.ERR)

PRIN.AMTS = R.LMM.BAL< LD27.OUTS.CURR.PRINC>

PRIN.CNT = DCOUNT (PRIN.AMTS, VM)

YR.AMT.BAL = R.LMM.BAL< LD27.OUTS.CURR.PRINC, PRIN.CNT>

Y.CURR = R.LMM.BAL< LD27.CURRENCY>

1.8 RE.LMM.BALANCES:

The table RE.LMM.BALANCES was made obsolete from R07 release instead a
single point for all Contract balances created as EB.CONTRACT.BALANCES.
 However In the below cases, we have depicted only for few important fields and
there corresponding R08 compliance fields in LMM.ACCOUNT.BALANCES.
Before Change:

$INCLUDE GLOBUS.BP I_F.RE.LMM.BALANCES

FN.RE.LMM.BALANCES = 'F.RE.LMM.BALANCES'
F.RE.LMM.BALANCES = ''
CALL OPF (FN.RE.LMM.BALANCES, F.RE.LMM.BALANCES)

CALL F.READ (FN.RE.LMM.BALANCES, Y.CNTR.ID, R.LMM.BAL, F.RE.LMM.BALANCES,

MMERR)

YR.AMT.BAL = R.LMM.BAL <RE.RLB.OUTS.CURR.PRINC>

CUST = R.LMM.BAL< RE.RLB.CUSTOMER.NO>

The above core fields have to be replaced to make the local routine compatible with R08.

After Change:

$INCLUDE GLOBUS.BP I_F.LMM.ACCOUNT.BALANCES

FN.LMM.ACCOUNT.BALANCES = ‘F.LMM.ACCOUNT.BALANCES
F.LMM.ACCOUNT.BALANCES = ‘’
CALL OPF (FN.LMM.ACCOUNT.BALANCES, F.LMM.ACCOUNT.BALANCES)

CALL F.READ (FN. LMM.ACCOUNT.BALANCES, Y.CNTR.ID, R.LMM.BAL,

F.LMM.ACCOUNT.BALANCES, LMMBAL.ERR)
PRIN.AMTS = R.LMM.BAL< LD27.OUTS.CURR.PRINC>
PRIN.CNT = DCOUNT (PRIN.AMTS, VM)
YR.AMT.BAL = R.LMM.BAL< LD27.OUTS.CURR.PRINC, PRIN.CNT>

IDESC = ‘CUSTOMER’
CALL IDESC (FN.LMM.ACCOUNT.BALANCES, Y.CNTR.ID, R.LMM.BAL, IDESC, RESULT)
CUST = RESULT
1.9 RE.MG.BALANCES:

The table RE.MG.BALANCES was made obsolete from R07 release instead a single
point for all Contract balances created as EB.CONTRACT.BALANCES.
In the below cases, we have depicted only for few important fields and there
corresponding R08 compliance fields in EB.CONTRACT.BALANCES.

Before Change:
$INCLUDE GLOBUS.BP I_F.RE.MG.BALANCES

FN.RE.MG.BALANCES = 'F.RE.MG.BALANCES'
F.RE.MG.BALANCES = ''
CALL OPF (FN.RE.MG.BALANCES, F.RE.MG.BALANCES)
CALL F.READ (FN.RE.MG.BALANCES, Y.CNTR.ID, R.RE.MG.BALANCES,
F.RE.MG.BALANCES, MGERR)

YR.AMT.BAL = R.RE.MG.BALANCES<MG.RBL.CURRENT.PRINCIPAL>
YR.INT.BAL = R.RE.MG.BALANCES<MG.RBL.ACCRUED.INTEREST>
YR.MAT.DATE = R.RE.MG.BALANCES<MG.RBL.MATURITY.DATE>
YR.NXT.INT.DTE = R.RE.MG.BALANCES<MG.RBL.NEXT.INT.DATE>

The above core fields have to be replaced to make the local routine compatible with R08.
In the below example, we have given the corresponding TAM routines to be called to extract
the individual fields value.

After Change:
$INCLUDE GLOBUS.BP I_F.EB.CONTRACT.BALANCES

FN.EB.CONTRACT.BALANCES = 'F.EB.CONTRACT.BALANCES'
F.EB.CONTRACT.BALANCES = ''
CALL OPF(FN.EB.CONTRACT.BALANCES, F.EB.CONTRACT.BALANCES)

MG.ID = Y.CNTR.ID [1,12]

CALL TAM.GET.LD.ECB.PRINCIPLE(MG.ID, MG.PR.AMT) ; * For calculating principal

amount
YR.AMT.BAL = MG.PR.AMT
 CALL TAM.GET.LD.ECB.ACCR.INT (MG.ID, MG.INT.AMT) ; * For calculating interest
amount
YR.INT.BAL = MG.INT.AMT

* For calculating MATURITY.DATE & NEXT.INT.DATE use the below routine.

CALL TAM.MAT.INT.DATE.CHECK (MG.ID, MAT.DATE, NEXT.INT.DATE)
YR.MAT.DATE = MAT.DATE
YR.NXT.INT.DTE = NEXT.INT.DATE

If we need to get the field values(RE.MG.BALANCES) apart from the ones given above, the below
information would be useful.

If in case the routine uses fields other than Principal Amount and Accrual interest
from RE.MG.BALANCES use the below table to get the corresponding field values in
higher releases.
DATE.LAST.UPDATED --> DATE.LAST.UPDATE from EB.CONTRACT.BALANCES
CURRENCY --> CURRENCY from EB.CONTRACT.BALANCES
FORWARD.PRINCIPAL --> OPEN.BALANCE + DEBIT.MVMT + CREDIT.MVMT under the
asset type FORWARDDB of EB.CONTRACT.BALANCES
CURRENT.PRINCIPAL --> OPEN.BALANCE + DEBIT.MVMT + CREDIT.MVMT under the
asset type LIVEDB of EB.CONTRACT.BALANCES (OR) Latest PRIN.BALANCES from
MG.BALANCES provided the PRIN.EFF.DATE is less than TODAY.
ACCRUED.INTEREST --> OPEN.BALANCE + DEBIT.MVMT + CREDIT.MVMT under the
asset type 51000 of EB.CONTRACT.BALANCES (or) OTS.INTEREST from MG.BALANCES
multiplied by (-1)
SUSP.INT --> OPEN.BALANCE + DEBIT.MVMT + CREDIT.MVMT under the asset type
51000SP of EB.CONTRACT.BALANCES (OR) OTS.SUSP.INT from MG.BALANCES
VALUE.DATE --> CONTRACT.VALUE.DATE of EB.CONTRACT.BALANCES
MATURITY.DATE --> MAT.DATE under the asset type LIVEDB (OR) MATURITY.DATE from
MG.MORTGAGE
NEXT.INT.DATE --> REPAYMENT.DATE (Frequency need to be truncated) from
MG.MORTGAGE or END.INT.PRIOD from MG.BALANCES
INTEREST.RATE --> INTEREST.RATE from EB.CONTRACT.BALANCES
INTEREST.KEY --> INTEREST.KEY from EB.CONTRACT.BALANCES
INTEREST.DAY.BASIS --> INTEREST.BASIS from EB.CONTRACT.BALANCES
CUSTOMER.NO --> CUSTOMER from EB.CONTRACT.BALANCES
1.10 ACCOUNT.DATE:

ACCOUNT.DATE has been made obsolete in R08. Hence any local routines using
DEBIT.DATES & CREDIT.DATES fields have to be replaced with ACCOUNT application
fields DEBIT.INT and CREDIT.INT respectively and the ACCOUNT.DATE table field
DEBIT.LIMIT should be replaced with EB.CONTRACT.BALANCES field DEBIT.MVMT.

1.11 POSITION.TABLE:

This table POSITION is made obsolete in R07 and POSITION need to be referred for
information.

1.12 ACCT.ACCT.ACTIVITY:

The file ACCT.ACCT.ACTIVITY has been made obsolete and the functionality got
changed to the new file EB.CONTRACT.BALANCES.

1.13 ACCT.ACTIVITY:

From R10 the file ACCT.ACTIVITY has been made obsolete and the functionality got
changed to the new file ACCT.BALANCE.ACTIVITY which holds the equivalent
ACCT.ACTIVITY records relating to arrangement accounts. The Local codes using
ACCT.ACTIVITY should be changed like below.

Before Change:
CALL F.READ (FN.ACCT.ACTIVITY,ACCT.ACT.ID,
R.ACCT.ACTIVITY,F.ACCT.ACTIVITY,ACC.ERR)
IF R.ACCT.ACTIVITY THEN
...
END

After Change:
CALL F.READ (FN.ACCT.BALANCE.ACTIVITY,ACCT.ACT.ID,
R.ACCT.BALANCE.ACTIVITY,F.ACCT.BALANCE.ACTIVITY,ACC.ERR)
IF R.ACCT.ACTIVITY THEN
...
END
1.14 COLLATERAL AND COLLATERAL.RIGHT:

EB.CONTRACT.BALANCES is now the common file which is updated by all applications. So

application level concat files of COLLATERAL and COLLATERAL.RIGHT are removed and the ids
are updated in new fields COLLATERAL and COLLAT.RIGHT of EB.CONTRACT.BALANCES. This is
done to avoid creating separate concat files for each application that is linked to
COLLATERAL/COLLATERAL.RIGHT.
FX.COLLATERAL
AC.COLLATERAL
LD.COLLATERAL
MM.COLLATERAL
MD.COLLATERAL
MG.COLLATERAL
FD.COLLATERAL

1.15 CHEQUES.PRESENTED AND CHEQUES.STOPPED:

In earlier releases FT and Teller update 2 cheque related concat files named
1. FXXX.CHEQUES.PRESENTED
2. FXXX.CHEQUES.STOPPED
These two concat files have been made obsolete and a new table
CHEQUE.REGISTER.SUPPLEMENT has been introduced.

1.16 SC.RATING:

Table SC.RATING is made obsolete from release R06 and the replacement table is
EB.RATING.
Hence all the Local Routine referring to the table SC.RATING should be changed to refer to the
table EB.RATING.

1.17 DE.PHANTOM.RUN:

DE.PHANTOM.CALL should be used instead of DE.PHANTOM.RUN, since

DE.PHANTOM.RUN is made obsolete.

Before Change:
MSG="DE.PHANTOM.RUN ROUTINE.NAME”
EXECUTE MSG
After Change:
MSG="DE.PHANTOM.CALL ROUTINE.NAME“
EXECUTE MSG
1.18 MD.EOD.LIST:

MD.EOD.LIST was holding duplicate data when compared to the tables MD.SCHEDULES &
MD.SCHED.DATES thereby in order to improve system performance MD.EOD.LIST had been made
obsolete and you can make use of either MD.SCHEDULES & MD.SCHED.DATES for your
requirement.

1.19 PM.POSN.REAL.TIME AND PM.POSN.VALUE.DATE:

From G132 release onwards, the file PM.POSN.REAL.TIME, PM.POSN.VALUE.DATE has

been made obsolete owing to performance related problems and the hence the file
PM.DLY.POSN.CLASS will be referred instead. All the Local routines referring to file
PM.POSN.REAL.TIME, PM.POSN.VALUE.DATE should be made to refer the table
PM.DLY.POSN.CLASS

1.20 DE.MM.O.END.OF.PERIOD & DE.MM.I.END.OF.PERIOD:

The DE.MM.O.END.OF.PERIOD/ DE.MM.I.END.OF.PERIOD applications have both been

made obsolete.
From R11, DE.EOP.OUTWARD, DE.EOP.INWARD multithread services will be used for
archiving the delivery related files (F.DE.O.HEADER/F.DE.I.HEADER).

1.21 POS.MVMT.LWORK.DAY:
The table POS.MVMT.LWORK.DAY has been made obsolete and the functionality got
changed to the new table POS.MVMT.HIST.

1.22 EB.COMPONENT:
The table POS.MVMT.LWORK.DAY has been made obsolete from R09 and the functionality
got changed to the new table SEAT.COMPONENT.

1.23 HEDGE.FRA:
The table HEDGE.FRA has been made obsolete from R05.

1.24 LIQ.TRADE:
The table LIQ.TRADE has been made obsolete from R08.
1.25 LOCKED.BALANCE.AMT:
The table LOCKED.BALANCE.AMT has been made obsolete from G11 and the functionality
got changed to the new table AC.LOCKED.EVENTS.

1.26 MG.INTEREST.KEY & MG.RATE.FIX.DTE:

The tables MG.INTEREST.KEY & MG.RATE.FIX.DTE have been made obsolete from R05.

1.27 RE.CONSOL.FOREX, RE.CONSOL.LOAN, RE.CONSOL.LOAN.SEQU,

RE.CONSOL.MM, RE.CONSOL.MM.SEQU, RE.CONSOL.PD, RE.CONSOL.PD.SEQU,
RE.CONSOL.SEC:
All the above tables have been made obsolete from R07 and the functionality got changed to
the new table RE.CONSOL.CONTRACT.

1.28 RE.CONTRACT.BALANCES:
The table RE.CONTRACT.BALANCES has been made obsolete from R07 and the
functionality got changed to EB.CONTRACT.BALANCES.

1.29 SA.PERMIUM.INTEREST.WRK & SA.PRM.INTEREST.WRK:

The tables SA.PERMIUM.INTEREST.WRK & SA.PRM.INTEREST.WRK have been made
obsolete from R08.

1.30 SC.TRADING.POSITION:
The table SC.TRADING.POSITION has been made obsolete from R07 and the functionality
got changed to EB.CONTRACT.BALANCES.

1.31 ACCOUNT MACROS:

Some of the fields in ACCOUNT application were moved to EB.CONTRACT.BALANCES.
From R12 release, some fields were called from EB.CONTRACT.BALANCES, using macros. They
are given below.

Before change :
CALL F.READ(FN.ACCOUNT,ACC.ID,R.RECORD,F.ACCOUNT,F.ERR)
C.BAL = R.RECORD<AC.WORKING.BALANCE>
After change
$INCLUDE T24.BP I_F.EB.CONTRACT.BALANCES
*C.BAL = R.RECORD<AC.WORKING.BALANCE>
CALL EB.READ.HVT("EB.CONTRACT.BALANCES",ACC.ID,R.ECB,ECB.ERR)
C.BAL = R.ECB<ECB. WORKING.BALANCE >

The following fields in ACCOUNT application are mapped to EB.CONTRACT.BALANCES

respectively.

ACCOUNT>OPEN.AVAILABLE.BAL EB.CONTRACT.BALANCES>OPEN.AVAILAB
LE.BAL

ACCOUNT>AVAILABLE.DATE EB.CONTRACT.BALANCES>AVAILABLE.DA
TE

ACCOUNT>AV.AUTH.DB.MVMT EB.CONTRACT.BALANCES>AV.AUTH.DB.M
VMT

ACCOUNT>AV.NAU.DB.MVMT EB.CONTRACT.BALANCES>AV.NAU.DB.MV
MT

ACCOUNT>AV.AUTH.CR.MVMT EB.CONTRACT.BALANCES>AV.AUTH.CR.M
VMT

ACCOUNT>AV.NAU.CR.MVMT EB.CONTRACT.BALANCES>AV.NAU.CR.MV
MT

ACCOUNT>FORWARD.MVMTS EB.CONTRACT.BALANCES>FORWARD.MV
MTS

ACCOUNT>NEXT.AF.DATE EB.CONTRACT.BALANCES>NEXT.AF.DATE

ACCOUNT>FIRST.AF.DATE EB.CONTRACT.BALANCES>FIRST.AF.DATE

ACCOUNT>OPEN.ACTUAL.BAL EB.CONTRACT.BALANCES>OPEN.ACTUAL.
BAL

ACCOUNT>WORKING.BALANCE EB.CONTRACT.BALANCES>WORKING.BAL
ANCE

ACCOUNT>ONLINE.ACTUAL.BAL EB.CONTRACT.BALANCES>ONLINE.ACTUA
L.BAL

ACCOUNT>ONLINE.CLEARED.BAL EB.CONTRACT.BALANCES>ONLINE.CLEAR
ED.BAL

ACCOUNT>OPEN.CLEARED.BAL EB.CONTRACT.BALANCES>OPEN.CLEARE
D.BAL

ACCOUNT>NEXT.EXP.DATE EB.CONTRACT.BALANCES>NEXT.EXP.DAT
E

ACCOUNT>INITIATOR.TYPE EB.CONTRACT.BALANCES>INITIATOR.TYP
E

ACCOUNT>AMNT.LAST EB.CONTRACT.BALANCES>AMNT.LAST
ACCOUNT>TRAN.LAST EB.CONTRACT.BALANCES>TRAN.LAST

ACCOUNT>DATE.LAST EB.CONTRACT.BALANCES>DATE.LAST

ACCOUNT>EXPOSURE.DATES EB.CONTRACT.BALANCES>EXPOSURE.DA
TES

1.32 AZ.ACCOUNT.HIST:
AZ.ACCOUNT.HIST file is made obsolete from R09 and the respective information is maintained in
AZ.ACCOUNT$HIS file.

1.33 RE.CONSOL.ACCT.HELD:
RE.CONSOL.ACCT.HELD is made obsolete from R10 and EB.CONTRACT.BALANCES application
needs to referred to get the open asset type information.

1.34 EB.SYSTEM.STATUS:
EB.SYSTEM.STATUS file is made obsolete from R13 and the information about system status during
fatal errors is now recorded directly in the TAFC log file.

1.35 DRAW.SCHEDULES:

Scheduled delivery messages from DRAWINGS application will update LC.SCHEDULES instead of
DRAW.SCHEDULES.

OBSOLETE FIELDS:
2.1 AC.CONSOL.KEY:

AC.CONSOL.KEY is a field in the Account application. This field was made obsolete, hence
any local sources using this field have to be changed to read EB.CONTRACT.BALANCES and then
to fetch CONSOL.KEY present in the same.

For Example:

Before Change:
CON.KEY = R.ACC<AC.CONSOL.KEY>

After Change:
FN.CONTRACT =”F.EB.CONTRACT.BALANCES”
F.CONTRACT = ‘’
CALL OPF (FN.CONTRACT, F.CONTRACT)

CALL F.READ (FN.CONTRACT, AC.ID, R.CONTRACT, F.CONTRACT, CONT.ERR)

CON.KEY = R.CONTRACT<ECB.CONSOL.KEY>
Note: Don’t forget to insert the I_F.EB.CONTRACT.BALANCES file in the insert section.

2.2 LD27.CONSOL.KEY
LD27.CONSOL.KEY is a field in the LMM.ACCOUNT.BALANCES application. This field was
made obsolete. Hence any local sources using this field have to be changed to read
EB.CONTRACT.BALANCES and then to fetch CONSOL.KEY present in the same.

For Example:

Before Change:
CON.KEY = R.LMM.ACCOUNT.BALANCES<LD27.CONSOL.KEY>

After Change:
FN.CONTRACT =”F.EB.CONTRACT.BALANCES”
F.CONTRACT = ‘’
CALL OPF (FN.CONTRACT, F.CONTRACT)

CALL F.READ (FN.CONTRACT, MM.ID, R.CONTRACT, F.CONTRACT, CONT.ERR)

CON.KEY = R.CONTRACT<ECB.CONSOL.KEY>

Note: Don’t forget to insert the I_F.EB.CONTRACT.BALANCES file in the insert section.

2.3 AC.ACCOUNT.CREDIT.INT -- AC.ACCT.CREDIT.INT:

i. From R07,the fields ACCOUNT.CREDIT.INT & ACCOUNT.DEBIT.INT in ACCOUNT is
changed to ACCT.CREDIT.INT & ACCT.DEBIT.INT respectively
ii. The fields ACCOUNT.CREDIT.INT & ACCOUNT.DEBIT.INT are Single value fileds in r06.
From R07, it’s changed as Multi value field in addition to the change in field name .

Before Change:
Y.ACI.ID = Y.ID:'-':R.ACC<AC.ACCT.CREDIT.INT>

After Change:
TEMP.ACI = R.ACC<AC.ACCT.CREDIT.INT>
CNT.ACI = DCOUNT(TEMP.ACI,VM)
Y.ACI.ID = Y.ID:'-':R.ACC<AC.ACCT.CREDIT.INT,CNT.ACI>

Before Upgrade:
After Upgrade:

2.4 MAINTAIN.POS.TABLE field in REVAUATION.PARAMETER:

From R07, the file REVALUATION.PARAMETER, the field MAINTAIN.POS.TABLE becomes
no-input because the POSITION.TABLE concat file is no longer maintained.

2.5 TT.TE.NEW.CUST.BALANCE  TT.TE.NEW.CUST.BAL:

From G15, the field named TT.TE.NEW.CUST.BALANCE in TELLER application is changed
to TT.TE.NEW.CUST.BAL.
Hence, all the local codes we are converting have to be checked for the above field names
and need to be converted with their corresponding equivalent field names in higher releases.
2.6 FREQU.RELATIONSHIP  ACCOUNT.STATEMENT
The field “FREQU.RELATIONSHIP” in ACCOUNT.STATEMENT application holds the value
which describes the mode of statement to be generated. The value it can hold is either “COMBINED”
or “SEPARATE”. The value COMBINED will be set to generate combined statements.
From R10, this functionality of generating combined statement using
FREQU.RELATIONSHIP field is unavailable and this field is made obsolete now.
For example:
The routine in which this option is used by checking the value for “COMBINED” along with
other conditions is shown below. Since this field is not available in R10 & it was not set as
“COMBINED” or “SEPRATE” for any of the ACCOUNT.STATEMENT records. Hence we are making
the changes to those routines based on four different cases which are described below with example.

Case 1:
1) Two conditions are checked in the ‘IF’ statement.
2) The 2nd condition for the value ‘FREQ.RELATION’ needs to be removed from the code.

Before change:
FREQ.RELATION = ''
CALL DBR
("ACCOUNT.STATEMENT":FM:AC.STA.FREQU.RELATIONSHIP,ACCOUNT,FREQ.RELATION)
IF FREQUENCY = 2 AND FREQ.RELATION # 'COMBINED' THEN
CALL OPF ("F.ACCT.STMT2.PRINT$ARC",F.ACCT.STMT.PRINT$ARC)
END ELSE
CALL OPF ("F.ACCT.STMT.PRINT$ARC",F.ACCT.STMT.PRINT$ARC)
END

After change:
FREQ.RELATION = ''
CALL DBR
("ACCOUNT.STATEMENT":FM:AC.STA.FREQU.RELATIONSHIP,ACCOUNT,FREQ.RELATION)
IF FREQUENCY = 2 THEN
CALL OPF ("F.ACCT.STMT2.PRINT$ARC",F.ACCT.STMT.PRINT$ARC)
END ELSE
CALL OPF ("F.ACCT.STMT.PRINT$ARC",F.ACCT.STMT.PRINT$ARC)
END

Case 2:
1) In this type of nested ‘IF’ statements, the 3rd ‘IF’ statement checks the condition whether
‘FREQU.RELATIONSHIP’ is not equal to ‘COMBINED’.
2) This 3rd ‘IF’ statement along with its ‘ELSE’ part needs to be removed from the code.

Before change:
IF YACCT.STMT.DATES<YPOS> = '' THEN
IF YSTORE.BAL.DATE = '' THEN
IF YR.ACCOUNT.STATEMENT<AC.STA.FREQU.RELATIONSHIP> <> 'COMBINED' THEN
YOPEN.BAL = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.BALANCE>
YSTORE.BAL.DATE = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.DATE>
END ELSE
IF YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.DATE> GE
YR.ACCOUNT.STATEMENT<AC.STA.FQU2.LAST.DATE> THEN
YSTORE.BAL.DATE = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.DATE>
YOPEN.BAL = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.BALANCE>
END ELSE
YSTORE.BAL.DATE = YR.ACCOUNT.STATEMENT<AC.STA.FQU2.LAST.DATE>
YOPEN.BAL = YR.ACCOUNT.STATEMENT<AC.STA.FQU2.LAST.BALANCE>
END
END
IF YOPEN.BAL = "" THEN YOPEN.BAL = 0
END
GOSUB READ.EXTRA.IDS:
GOSUB GET.ENTRIES.EQ
END ELSE
END

After change:
IF YACCT.STMT.DATES<YPOS> = '' THEN
IF YSTORE.BAL.DATE = '' THEN
IF YR.ACCOUNT.STATEMENT<AC.STA.FREQU.RELATIONSHIP> <> 'COMBINED' THEN
YOPEN.BAL = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.BALANCE>
YSTORE.BAL.DATE = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.DATE>
END ELSE
IF YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.DATE> GE
YR.ACCOUNT.STATEMENT<AC.STA.FQU2.LAST.DATE> THEN
YSTORE.BAL.DATE = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.DATE>
YOPEN.BAL = YR.ACCOUNT.STATEMENT<AC.STA.FQU1.LAST.BALANCE>
END ELSE
YSTORE.BAL.DATE = YR.ACCOUNT.STATEMENT<AC.STA.FQU2.LAST.DATE>
YOPEN.BAL = YR.ACCOUNT.STATEMENT<AC.STA.FQU2.LAST.BALANCE>
END
END

IF YOPEN.BAL = "" THEN YOPEN.BAL = 0

 END
GOSUB READ.EXTRA.IDS:
GOSUB GET.ENTRIES.EQ
END ELSE
END

2.7 AC.MKT.ACTUAL.BAL:
AC.MKT.ACTUAL.BAL field in ACCOUNT application has been made OBSOLETE from G13.
The local codes using this field should be changed to fetch the value from field
OPEN.AVAILABLE.BAL.

Before Change:
IF R.ACCOUNT<AC.OPEN.ACTUAL.BAL> <> R.ACCOUNT<AC.MKT.ACTUAL.BAL> THEN
R.ACCOUNT<AC.MKT.ACTUAL.BAL> = R.ACCOUNT<AC.OPEN.ACTUAL.BAL>
END

After Change:
IF R.ACCOUNT<AC.OPEN.ACTUAL.BAL> <> R.ACCOUNT<AC.OPEN.AVAILABLE.BAL> THEN
R.ACCOUNT<AC.OPEN.AVAILABLE.BAL> = R.ACCOUNT<AC.OPEN.ACTUAL.BAL>
END

2.8 AC.PREV.OPEN.BAL:
AC.PREV.OPEN.BAL field in ACCOUNT is made OBSELETE from G13. The CORE routine
EB.GET.ACCT.BALANCE can be used to get the value PREV.OPEN.BAL

Before Change:
CALL F.READ(FN.ACCOUNT,ACC.ID,ACC.REC,F.ACCOUNT,ERR)
Y.PREV.OPEN.BAL = ACC.REC< AC.PREV.OPEN.BAL>

After Change:
CALL F.READ(FN.ACCOUNT,ACC.ID,ACC.REC,F.ACCOUNT,ERR)
BALANCE.DATE = TODAY
CALL CDT("", BALANCE.DATE, "-2W")
CALL EB.GET.ACCT.BALANCE (ACC.ID, ACC.REC, "BOOKING", BALANCE.DATE, "",
PREV.OPEN.BAL.VALUE, "", "", ERR.MSG)
Y.PREV.OPEN.BAL = PREV.OPEN.BAL.VALUE

Note: EB.READ.HISTORY.REC
Reads the Latest History Record
"Arg.1 - Used to store the FileVariable of the History file
Arg.2 - Used to store the id for which the History file to be read"
outgoing arg
"Arg2 - Returns the latest history ID Arg.3- Contains the Latest History Record for the id
Arg.4 - Conatins the error Messages if any
"
"FN.ACCOUNT$HIS='F.ACCOUNT$HIS'
F.ACCOUNT$HIS=''
Y.ID=40495
CALL OPF(FN.ACCOUNT$HIS,F.ACCOUNT$HIS)
CALL EB.READ.HISTORY.REC (F.ACCOUNT$HIS,Y.ID,R.ACCOUNT$HIS,Y.ERR)
O/P:Y.ID = 40495;7 R.ACCOUNT Contains the Latest History Record for the Account
Number 40495;7

Note: The Obsolete tables are tabulated below.

OBSOLETE Routines:
RE.EXTRACT.ACCOUNT.NOS is obsolete from R07:
Subroutine RE.EXTRACT.ACCOUNT.NOS is obsolete from R07. It is used to extract the
contract ids from RE.CONSOL.ACCOUNT and SEQU file .As now all the details are maintained
under the roof RE.CONSOL.CONTRACT we need to remove the CALL
RE.EXTRACT.ACCOUNT.NOS and do F.READ for RE.CONSOL.CONTRACT file.

RE.EXTRACT.LC.INFO is made obsolete:

In G14 release, to obtain the contracts balances the routines such as
RE.EXTRACT.LC.INFO, RE.EXTRACT.LD.INFO and RE.EXTRACT.FX.INFO etc., will be invoked.
These routines will read the contracts details from the corresponding files and return back that
information.
In R08, the above process flow was changed. Instead of invoking the application routines to
obtain balances, the routine RE.EXTRACT.APP.INFO will be invoked. This routine will obtain the
balances for the application that are update in EB.CONTRACT.BALANCES. For the application (FR,
FD etc.,) that are not included in EB.CONTRACT.BALANCES, the corresponding application routine
(RE.EXTRACT.FR.INFO, RE.EXTRACT.FD.INFO etc.,) will be invoked to obtain the balances & the
values of the fields requested.

GM.CHK.HOLIDAY is made obsolete:

The subroutine GM.CHK.HOLIDAY is used to check whether a date is "HOLIDAY" or not.
This core routine GM.CHK.HOLIDAY is obsolete from R09 Release. Hence it is replaced with core
API “AWD”.
Before Conversion

A = ''
 B = ''
 C = ''
 DEFFUN GM.CHK.HOLIDAY (A,B,C)
 IF GM.CHK.HOLIDAY (Y.COUNTRY,Y.ZONE,Y.DEP.VAL.DATE) = 'Y' THEN
    Y.CURR.NO = DCOUNT (R.NEW(AC.OVERDUE.STATUS),VM) + 1
    TEXT = 'Value Date is Holiday  ' : Y.DEP.VAL.DATE
    CALL STORE.OVERRIDE (Y.CURR.NO)
    IF (TEXT = "NO") THEN RETURN
 END

Routine Syntax:
 CALL AWD(ARG.1,ARG.2,ARG.3)
Incoming parameter
Arg. 1 - Contains the region code
Arg. 2 - Contains start date in YYYYMMDD

Out Going parameter

Arg. 3 - Contains the H  (Holiday) or W (Working day) or N (Not available in HOLIDAY table)

After Conversion

CALL AWD(Y.ZONE,Y.DEP.VAL.DATE,HOLI.CHK)
IF HOLI.CHK EQ "H" THEN
    Y.CURR.NO = DCOUNT(R.NEW(AC.OVERDUE.STATUS),VM) + 1
    TEXT = 'Value Date is Holiday  ' : Y.DEP.VAL.DATE
    CALL STORE.OVERRIDE(Y.CURR.NO)
    IF (TEXT = "NO") THEN RETURN
 END

SC.GET.SECURITY.POSITION.LIST:
Call(s) to SC.GET.SECURITY.POSITION.LIST has been replaced by DAS() calls in core
routines.
FWDRATES.REVAL:
The Routine FWDRATES.REVAL is Obsolete in R10. If you want to get the Premium Rate
form the FORWARD.RATES table, then you can use the routine FWDRATES. For exchange rate
calculation, you can refer the routine EXCHRATE.

DRAW.EOD.SCHEDULES:
Job DRAW.EOD.SCHEDULES has been removed from LC.END.OF.DAY batch. All scheduled
delivery messages will be processed as part of LC.EOD.PROCESS.SCHEDULES batch job.

SPECIAL CASES:
ACCT.ENT.TODAY
ACCT.ENT.TODAY table though not made as obsolete, its process flow has been changed.
In COB, ACCT.ENT.TODAY will be get cleared in SYSTEM.END.OF.DAY3 (Batch Stage
S012). So BATCH routines attached after this job have to be changed and routed to
ACCT.ENT.LWORK.DAY as mentioned below:

Before Change:
FN.ACCT.ENT.TODAY=’F.ACCT.ENT.TODAY’
FV.ACCT.ENT.TODAY=’’
CALL OPF (FN.ACCT.ENT.TODAY, FV.ACCT.ENT.TODAY)
After Change:
FN.ACCT.ENT.TODAY=’F.ACCT.ENT.LWORK.DAY’
FV.ACCT.ENT.TODAY=’’
CALL OPF (FN.ACCT.ENT.TODAY, FV.ACCT.ENT.TODAY)

CATEG.ENT.TODAY
CATEG.ENT.TODAY table though not made as obsolete, its process flow has been changed.
In COB, CATEG.ENT.TODAY will be get cleared in SYSTEM.END.OF.DAY5 (Batch Stage S025). So
BATCH routines attached after this job have to be changed and routed to CATEG.ENT.LWORK.DAY
as mentioned below:

Before Change:
FN.CATEG.ENT.TODAY=’F.CATEG.ENT.TODAY’
FV.CATEG.ENT.TODAY=’’
CALL OPF (FN.CATEG.ENT.TODAY, FV.CATEG.ENT.TODAY)
After Change:
 FN.CATEG.ENT.TODAY=’F.CATEG.ENT.LWORK.DAY’
FV.CATEG.ENT.TODAY=’’
CALL OPF (FN.CATEG.ENT.TODAY, FV.CATEG.ENT.TODAY)

CONSOL.ENT.TODAY
CONSOL.ENT.TODAY table though not made as obsolete, its process flow has been
changed.
In COB, CONSOL.ENT.TODAY will be get cleared in SYSTEM.END.OF.DAY5 (Batch Stage
S025). So BATCH routines attached after this job have to be changed and routed to
CONSOL.ENT.LWORK.DAY as mentioned below:

Before Change:
FN.CONSOL.ENT.TODAY=’F.CONSOL.ENT.TODAY’
FV.CONSOL.ENT.TODAY=’’
CALL OPF (FN.CONSOL.ENT.TODAY, FV.CONSOL.ENT.TODAY)
After Change:
FN.CONSOL.ENT.TODAY=’F.CONSOL.ENT.LWORK.DAY’
FV.CONSOL.ENT.TODAY=’’
CALL OPF (FN.CONSOL.ENT.TODAY, FV.CONSOL.ENT.TODAY)

ACCOUNT.ACT
ACCOUNT.ACT records will be updated only when relevant fields set in consolidation
parameters. It won’t get updated whenever the account or arrangement is updated.

AA.CONVERT.NEXT.ACTIVITY
A new service AA.CONVERT.NEXT.ACTIVITY has been introduced. This service will delete
the COB activity ids (activities got updated before upgrade) from the AA.NEXT.ACTIVITY and will
copy to the corresponding product line list file.

AUTO NEW CONTENT:

Auto New content routine will not trigger using the reverse or deletion. Hence the functionality
to be achieved using Auto new content during Reverse or Deletion, should be achieved using Check
Rec routine.

ACCT.ENT.FWD :
Before R07, all the future value dated entries and forward entries (F entry) are stored in
ACCT.ENT.FWD, on the value date they will be moved to ACCT.ENT.TODAY. But now from R07 all
the future value dated will be there in ACCT.ENT.TODAY itself.
DE.MM.O.END.OF.PERIOD & DE.MM.I.END.OF.PERIOD:
To make faster archival process and multi-threaded two services DE.EOP.OUTWARD,
DE.EOP.INWARD services are introduced which has to be used for outward and inward end of period
processing respectively.
The DATA field in the batch record of the services DE.EOP.OUTWARD and
DE.EOP.INWARD can be used to give the purge date before which you wanted to remove the
records. The corresponding F.DE.O.HEADER.ARCH / F.DE.I.HEADER.ARCH and
F.DE.O.MSG/F.DE.I.MSG are deleted.

GET.CREDIT.CHECK:

The parameters in the core routine had been changed and extra parameters are added as
follows.

Before Conversion:
CALL GET.CREDIT.CHECK(CR.CHECK, MAT R.ACCOUNT, R.AGC)
After Conversion:
LOCKED.WITH.LIMIT = ''
AVAIL.BAL.UPD = ''
LOCK.INC.MVMT = ''
CALL GET.CREDIT.CHECK(CR.CHECK, LOCKED.WITH.LIMIT, MAT R.ACCOUNT, R.AGC,
AVAIL.BAL.UPD, LOCK.INC.MVMT)

AVAIL.FUNDS.UPDATE:
The parameters in the core routine had been changed and extra parameters are added as
follows.

Before Conversion:
CALL AVAIL.FUNDS.UPDATE(ACC.ID, MAT
R.ACCOUNT,AMOUNT,AF.DATE,'',FORWARD,REV.IND,REC.STATUS,TRANS.TYPE,TRANS.COD
E, OVERRIDE)
After Conversion:
AC.AVAIL.BAL.DET = ''
CALL AVAIL.FUNDS.UPDATE(ACC.ID, MAT
R.ACCOUNT,AMOUNT,AF.DATE,'',FORWARD,REV.IND,REC.STATUS,TRANS.TYPE,TRANS.COD
E, OVERRIDE,AC.AVAIL.BAL.DET)

With respect to RE.MG.BALANCES changes in our LCC, the information provided in the guide is only
for getting Principal amount and Interest amount using the TAM
rtns TAM.GET.LD.ECB.PRINCIPLE, TAM.GET.LD.ECB.ACCR.INT and TAM.MAT.INT.DATE.CHEC
K
 
Annexure:

TAM.GET.LD.ECB.PRINCIPLE (CONTRACT.ID, LD.PR.AMT)

This routine will calculate and return the equivalent principal amount of the field
OUTS.CURR.PRINC (RE.LD.ACC.BAL\RE.MG.BALANCES) by reading the corresponding
EB.CONTRACT.BALANCES record.
The routine has 2 arguments.
Incoming argument
CONTRACT.ID: The contract @id has to be given.
Outgoing argument
The second argument LD.PR.AMT will be return with OUTS.CURR.PRINC equiv amt.

TAM.GET.LD.ECB.ACCR.INT (CONTRACT.ID, LD.INT.AMT)

This routine will calculate and return the equivalent interest amount of the field
OUTS.ACCRUED.INT (RE.LD.ACC.BAL\RE.MG.BALANCES) by reading the corresponding
EB.CONTRACT.BALANCES record.
The routine has 2 arguments.
Incoming argument.
CONTRACT.ID: The contract @id has to be given.
Outgoing argument
The second argument LD.INT.AMT will be return with OUTS.ACCRUED.INT equiv amt.

TAM.MAT.INT.DATE.CHECK (MG.ID, MAT.DATE, NEXT.INT.DATE)

This routine will calculate and return the equivalent maturity date and next interest date of the
fields MATURITY.DATE and NEXT.INTEREST.DTE in (RE.LD.ACC.BAL), MATURITY.DATE
and NEXT.INT.DATE in (RE.MG.BALANCES) by reading the corresponding
EB.CONTRACT.BALANCES record.
The routine has 3 arguments.
Incoming argument.
MG.ID: The contract @id has to be given.
Outgoing arguments
The second and third argument MAT.DATE, NEXT.INT.DATE will be return with equiv
MAT.DATE and NEXT.INT.DATE will also be calculated from MAT.DATE (Based on today’s
date).