Design Concepts

Program Design Concepts

		Program Modules
		Three types of program task exist:

On-line Tasks

These are interactive real-time tasks executing on user workstations during normal daytime operations. A typical example would be Deal Entry or Position Reporting.

Background Real-time Tasks

These are iterative real-time tasks that usually run on dedicated background machines during normal daytime operations. Examples would be RATEFEED (handling continual rate acceptance to the system) or REVALS (performing continual positional revaluations).

Background Batch Tasks

These are batch tasks that would normally run on background machines during the overnight cycle. A typical example would be the NEWDAY rollover process.

Object Classification

Function	APL Program - an executable object within an APL workspace
Variable	APL data array variable used in a workspace
File	APL or DOS file
Program Module or Group	Logical association of Functions, Variables and Files necessary for the execution of a given task.

		Code Structures
		Specific program modules combine code and data into functional modules or groups by relating individual functions, variables and files (via logical file references see File Design Concepts). Each group or module can be regarded as a functional object or sub-system.
		An on-line process or background task is executed by loading a specific module of code into the active workspace, the task is then initiated by a call to the top level function of the group.
		APL is an interpreted programming language hence the functions are both source and object code, there is no separate object code version. This structure enables the linking of objects into executable tasks to be automatically handled within the system file utilities, no separate link libraries are required. Therefore a only single coherent version of the system code needs to be maintained.
		The Menu structure controls the access and calling structure of the on-line tasks. Whilst the Background Task scheduler controls the sequence and calling structure of the batch and real-time background tasks.
		Naming Conventions
		Naming conventions are followed for the various classes of objects found in the programming environment.
		Code modules, tasks and functions have related names, e.g. the NEWDAY task is performed by the NEWDAY program group, the top level routine of which is also called NEWDAY. There are standard prefixes for all functions in a group. Variables have names related to their usage and the functions that modify them.
		Global workspace variables are identified by lower case names.
		Line labels are clearly delineated, for start and end of loops, error handling, exit points, etc.
		Screen objects have a common naming format (name of image, data to write, validation statements, etc. See Screen - Handling Variables).
		Object Libraries
		Objects are stored in one or more system files depending on the facilities implemented at a given site. Functions are stored in standard APL format, that is a character string, each line of code being delimited by a carriage return character. Variables are stored in a packed form created by the "PACK" data compression utility (refer to Powertools utilities tPACK and tUNPACK)
		Each object has a status (disabled or active), a type; (function or variable), a location and a changed flag (i.e. last changed by particular team member). Additionally, functions have a header comment giving the version number, time and date of last change and the name of the support team member who made the change, which will reinforce the changed flag information.

File Design Concepts

Directory Organisation

Figure: Directory Tree Structure

		The LIVE directory
		4XTRA data resides on a network file server where live data is stored in a directory named as S:\4XTRA\LIVE. There are a further three sub-directories that relate to major sets of data (see below)
		The BGND directory
		Background machines duplicate the LIVE data and data structures to service background processing, this device also provides fault tolerance and addresses performance considerations. The integrity of these multiple copies of data is preserved by the background task scheduler.
		The BGND directory is also used for a copy of the console control file (which is used to co-ordinate the overnight run across the various background PCs) and other temporary files which stand outside or above the overnight run itself.
		The major sets of 4XTRA data:
		DATA -
		On the "server" this directory holds all files other than position files and external feeds, which are used by the on-line facilities.
		Locally, it is the temporary area for files produced by the last batch task.
		Data directory cycle
		The main file activity in an overnight run occurs within the BGND\DATA directory.
		Any files in the overnight that are written to, must be in the DATA directory, whether the file is created from scratch, written to serially or updated on a random access basis.
		All files in the LIVE\DATA directory on the server are copied to the BGND\DATA\CLOSE directory on the local drive.
		Upon completion of a task the files in the BGND\DATA directory are compared to the files in the BGND\DATA\CLOSE directory.
		If an earlier version is present in the CLOSE directory, the new version is assumed to be needed for the next trading day. The file is copied to the server LIVE\DATA\END directory and moved to the local BGND\DATA\END directory.
		If the file is not found in the CLOSE directory, it is assumed to be a file for passing information between tasks, and not for use the next day. It is copied to the server LIVE\DATA\DURING directory and moved to BGND\DATA\DURING locally.
		If a single stand alone machine is running the batch (in the case of, say, a network failure) the copies to the server are naturally omitted, but the file moves between CLOSE, DURING and END still occur.
		POSN - Position or Ladder Files
		A position or ladder file exists for every 'currency pair position` combination traded to. On the server the LIVE\POSN contains the current on-line ladder files. Locally it is empty.
		The position files are updated at only two points in the overnight sequence:
		Upon processing any deals from a batch-fed external load, which creates the DURING version of the positions.
		By the NEWDAY task, which does the final revaluation, profit and loss sell off and rolls the files to the new working day, which creates the END and NEWDAY versions of the positions.
		Positional directory cycle
		The sub-directories contain the various intermediate processing stages produced by the batch run:
		BEGIN the positions as at the start of the trading day i.e. before being updated by any trading activity.
		CLOSE the positions as updated by the dealers during a trading day (and verified by the LADDERS task).
		DURING the positions during overnight run, after any intermediate changes but before final revaluation and roll on to new day.
		END is the final close of business positions after any external update, after the final revaluation (with closing rates) and before the profit sell off.
		NEWDAY positional files as at the end of the Overnight Run and prepared for the following days trading. Note NEWDAY will be the BEGIN version for the next day.
		On a batch processor's local drive there are no files in the POSITION directory itself. The server copies of the previous day's NEWDAY files are switched to BEGIN, and the POSITION directory files to CLOSE by the first task of the overnight.
		EXTL - External Data
		Held in sub-directories under EXTL are three sub-sets of external data.
		Import - Repository for data being imported into 4XTRA. files are read-only.
		Export - Write-only by convention - destination for exported data.
		Report - Reports are created locally, one copy per recipient, plus a copy for on-line browsing.
		When the files have been sent to the printer, the reprint /browse file is copied to the server and the user copies deleted. All Machines involved in the batch take a local copy of every report spool image, import and export file.
		Logical File Names
		No 4XTRA task, either on-line or in the overnight batch, makes direct reference to a file name. All processes use logical file names from a central directory. The pointers from these names to actual DOS files are also held in this directory. It is this feature which allows the system to utilise separate data sets on the same network, switch drives and so on without effecting the system code.
		For any task to access a file (the on-line day is considered to be a single task) it must have a group definition on the logical names file which contains the reference name(s) it can use to manipulate the files. This enables the utilities to identify all parts of the system which refer to a given file. File groups are organised in the same way, and manipulated by the same utilities, as the system file.
		File Structures
		File structures are standardised, with reserved records, standard directory layouts and locations, file descriptors etc. For individual file descriptions refer to the document 4XTRA System Documentation - File Descriptions.

[4xtra Features] [Overview] [Using The System] [Developers] [Administrators]