This section covers general programming techniques that should be used to make the code easier to read and additional general LIFEfit specific programming techniques.

a.  IF ... THEN ... ELSE statement

  • Ensure the construct is easy to read
  • Don't write:


.. Statements


  • Write:

IF VALID<>5 THEN               or                          IF VALID = 5 THEN

.. statements                                                                 NULL

END                                                                      END ELSE

... statements


  • Keep to the following construct:






  • And NOT:


  • Distinction should be made between values null and '0'. For example when checking if value had been put into a screen field the variable should be checked like this: IF WC_IS%<>'' THEN because in some cases 0 is also a value.

> Top <

b. Case statement

  • LIFEfit’s strength is its flexibility.  The changes that we make today will be changed again in the near future.  If you are adding a calculation to an existing calculation routine, then always use a CASE statement.  IF…END ELSE.. Works for binary choices, but will be a mess the third time round.
  • If you use a CASE statement, make sure the code is easy to read and if the code is too long then create an internal subroutine.

DO:                                                     NOT:

BEGIN CASE                                       BEGIN CASE

   CASE CODE = PARM                          CASE CODE = PARM

        GOSUB AGE_CHECK                          (Page of code)

   CASE CODE = PARM                          CASE CODE =  PARM

        GOSUB OCC_CHECK                          (half a page of code)

END CASE                                          END CASE

CASE 1                                               CASE 1

CALL LF.MESSAGE.SB ('LF009', ", ", program name:field mark:func:field mark:programe version number)


  • Always add CASE 1 when a new case statement is added to a program, and use the error message LF009..


> Top <

c. Displaying messages

  • Do not use MSG, SB.DISP or CRT in your code – if you do, the new Upgrade Procedure will refuse to download that program.  Use the standard function (LF.MESSAGE in Advanced Revelation and LF.MESSAGE.SB in Universe) to display a message to the screen or to print any messages in a report file.

d. Semicolons

  • Do not use semicolons to put multiple statements on a line (except comments).  Keep lines simple.

DO                                                                   NOT

VAL = 0 ; * Initialise value                                * Initialise Variables

IINCR = 1 ;* Initialise increment                        VAL = 0;INCR=1


> Top <

e. Future file

  • FUTURE records should contain the minimum of information.  It should be required only to have the key information, the COMPANY CD, and DATE and TIME of request.  This will minimise the overhead in creating or amending future records.  FUTURE records for forward switches, surrenders, income payments, etc should also contain the key to the related record in the UNITSWITCH QUOTE or IPAYMENT record respectively.
  • Wherever possible, FUTURE records should be written from a central routine, LFS_FUTURE

f. Changes to codes

  • If a code is being changed (i.e. from number to alpha), check for uses of that code throughout the system.

g. Insert files

  • Never use field position numbers in your programs, always use equates from the insert file.   The equate entry in the insert file should match the dictionary field name i.e.:
  • Premium_Received fields on the POLICY file.
  • The insert file POLICY_INS should contain PO$PREMIUM_RECEIVED
  • On the UniVerse system, the insert files contain version numbers.  Update the version number when the insert file is changed.  The format for version number is and resides on line 4.

> Top <

h. Screen based programs

i. Field processing:

  • Only one Parameter should be passed from a screen which should adhere to the following standard format:

PRE_fieldname                         Pre prompt process call

POST_fieldname                       Post-prompt process call


  • (Note: A case could also be made for ‘VALID_’, ‘SET_’, ‘GET_’, ‘DEFLT_’ as alternative prefixes where these are more descriptive.)
  • ‘PRE_action’ or ‘POST_action’ where action is of the form ‘SAVE’, ‘INIT’ ‘DELETE’ or other action or event associated with the screen as a whole  ‘PERPETUAL’ for a perpetual process
  • The main section of the program should consist of a CASE construct, with one CASE statement per parameter option, and terminated with a RETURN. A ‘CASE 1’ error procedure should trap and report any invalid options.  Each non-trivial case should branch to an appropriately named internal subroutine.  The name of internal subroutine should be the same as the passed parameter.

ii. Softkeys:

  • Options should have descriptive names, not function key numbers
  • Soft Key options launching a complex screen or process should be limited to setting parameters and invoking an external subroutine.

> Top <

i. Input/output statements

  • Never use OPEN, READ, WRITE DELETE statements in your programs.  There are sets of standard programs to do this.  These programs start with LFSIO and are listed below:

LFSIO_STATUS                                 I/O status file

LFSIO_CODES                                  I/O Codes file

LFSIO_FUTURE                                 I/O Future file

LFSIO_COMMTYPES                         I/O COMMTYPES file

LFSIO_GENACCTRN                          I/O GENACCTRN file

LFSIO_COMMENTRY                         I/O COMMENTRY file

LFSIO_UNITMOVES                           I/O  UNITMOVES file

LFSIO_PLANS                                   I/O  PLANS file

LFSIO_MASTER                                I/O MASTER file

LFSIO_POLACCTRN                          I/O POLACCTRN file

LFSIO_UNITACCTRN                         I/O UNITACCTRN file

  • Input / output to any other data file  should use LFSIO_DATAFILE.
  • There is no need to open the datafile before the read.  Call the LFSIO process with READ parameter, it will open and read the file.
  • When saving a numeric value onto a datafile, ensure that the value is rounded before it is saved, i.e. if 1234.5678900 is being saved onto the policy, round this before storing onto the policy, save as 12345.

> Top <

j.  Batch processes

i. Batch message:

  • Use the standard batch message LF_BATCH_MSG in the batch processes.  This message shows the progress of the batch process by showing the total number of records to process and the number completed.

ii. Reports:

  • Report page and column headings should be created using the standard Lifefit programs LF_COLHEAD and LF_PAGEHEAD.
  • The report number should be added to the LF_MASK for new reports.  All new report number as of now will start from 1000.  When a new report number is required, check the last number used and increment by one


    e.g.    first new report - REPORT_1000      
    second new report - REPORT_1001

    Add the new report number to the codes record REPORT_TITLES


iii. Policy status:

  • NEVER use PO$POLICY_STATUS_CD or PO$STATUS_CD directly in conditional statements (IF, CASE), these fields hold the external status code which is user configurable. If comparisons in the program are made against the external status code then that is like hard coding the statuses within the program. The client has the ability at any point to change the external status code but what will remain constant is the real status (Status Type field on the status set-up screen). Policy status comparisons should be made against the REAL status.

  • There is a standard program that returns the REAL status:



> Top <

iv. Batch status change:

  • When setting up a new automated status change, batch process ensure LFSCH_WRAPUP is called to do the status change.  The batch process should build up the parameters and call LFSCH_WRAPUP.  This will ensure that the batch and the on-line status change processes are consistent.

k.  Tools

There are tools available to assist with development:

i. UVEditor:

  • Always  use the Uveditor when editing programs or inserts.

ii. SSCAN search:

  • If you are changing an existing program or want to know how a field works, use SSCAN in AREV or the search functionality in the UVeditor to help you.
  • These functions look through a designated table for a given string.  The string search should be using the least common denominator.  If you are looking for enhancements to trailer commissions, then use the string PL$TRAIL rather than PL$TRAILER_COMMISSION.  This will catch all PL$TRAILER or PL$TRAILS, etc. etc.  This will produce a list of items where the required string is used, in AREV a BROWSE LIST will be created for easy analysis.

iii. family_tree:

  • If you are modifying a program or are unsure of the implications of a change to a program, then run FAMILY_TREE in AREV or the Family tree option in UVEditor to will give you a top-down look at the subroutine in question and all the routines that are called from this routine.  The POPUP window will allow you to edit any of the called programs.

> Top <

l. New pseudos

  • Avoid using the underscores when defining new accounting pseudos.

m. Rounding

  • If developers are updating numeric fields through a program, then they should check the data by editing the record to ensure the data is rounded.  A problem has been discovered with INT when rounding negative numbers.  User MR0 conversion instead of the INT function.

> Top <