Thursday, March 25, 2010

Peephole Optimization

Jack Dikian

January 1992


In the late 70’s and early 80’s when the 8086 (The IBM PC) was running at 4.77Mhz and incapable of addressing more than 16MB of hardware memory (in real mode) – and even when minicomputers of the day such as the 16bit PDP11/xx range where running at around 15Mhz with a largely orthogonal instruction-set architecture and little I/O instructions – those involved in compiler design and implementation, such as myself working mainly with early versions of Unix sought to reduce both the compilation time and execution time of programs in order to combat the limitations of hardware of the time.

Successful compiler optimizers were required to produce a faster executable code, moderate compilation time and effective use of resources such as memory. Understanding compiler optimization was essential, particularly when changes to a programming construct or to an instruction set was required – the changes to the compilation process must be taken into consideration.

Instruction execution on any given processor is performed at the machine level, often using a machine language or machine code. However, most code is written in a higher-level language such as LISP, C or C++. Therefore, the important role of optimizing code is normally done by compilers, translating high-level languages into machine code. Given that system architectures vary dramatically, how code is executed against anyone processor class also varies greatly. For example, the Pentium processor has two separate integer execution units, called the U-pipe and the V-pipe. The U-pipe can execute any instruction while the V-pipe can only execute a subset. Programs that take this into account, for instance, can structure themselves in ways to achieve improved performance over those that do not optimise themselves in this manner.

Particular interest to the author was the "back end" compiler optimization techniques such as the peephole methods, and the exploration of the relationship between compiler optimization and the given architecture and design.

Compiler Optimization

Most compilers perform lexical, syntactic, and semantic analysis, code optimization, and code generation, in this order. Code optimization includes common sub-expression elimination, constant folding, code motion, and strength reduction.

Code generation includes register allocation, code selection, and perhaps some peephole optimization. Most optimizers treat a high-level intermediate code to avoid machine dependencies and most peephole optimizers are machine specific and ad hoc, so they are normally confined to correcting a small sample of patterns that cannot be more easily corrected before code generation.

Peephole optimization

Generally, peephole optimization is used to mean the pattern matching and conditional replacement performed on small set of intermediate instructions. The circular dependence between the code generation phases implies that local optimals are rarely global optimals. Some strategies that may be adopted are:

  • Accept the local optimal
  • Develop intermediate goals whose achievement suggest global optimality
  • Retain the choices so that the decisions can be made later
  • Optimize the object by replacing awkward or overly constrained segments of code with improved ones.

As mentioned, peephole optimization is performed over a small set of instructions in a segment of generated code. The set is called a "peephole" or a "window". The peephole optimizer works by recognising sets of instructions that perform a NULL outcome (they do nothing), or that can be replaced by more efficient set of instructions. The most common techniques used in peephole optimization include:

  • Evaluating constant sub-expressions in advance.
  • Replacing slow operations with faster equivalents.
  • Deleting useless operations
  • Replacing several operations with one equivalent.
  • Use algebraic laws to simplify instructions.
  • Using special purpose instructions designed for special operand cases.

Peephole optimization examples

Treatment of single instructions with a constant operand

l A * 2 = A + A

l A * 1 = A

l A * 0 = 0

l A / 1 = A

Replacing the Multiply operation with a Shift

l A := A * 4;

Can be replaced by 2-bit left shift (signed/unsigned)

Folding jumps to jumps

A jump to an unconditional jump can copy the target address

JNE label 1


Label 1: JMP Label 2

Can be replaced by

JNE Label 2

As a result, Label 1 may become dead (unreferenced)

Jump to Return

A jump to a Return can be replaced by a Return

JMP label 1


Label 1 RET

Can be replaced by


Label 1 may become dead code

Wednesday, March 24, 2010

Parenthesised Road Of Lisp

Jack Dikian

December 1998


Back in the 1980’s the author was involved in writing a formal (limited) grammar to support the development of an “expert” system to deal with the diagnosis and configuration of Unix file systems.

When reviewing a number of artificial (programming) languages we become interested in LISP. We realised that it’s strong expressive language for stating computational linguistics and flexible data constructs might meet the needs of yet to be fully defined project.

We were particularly interested in manipulating symbols (words, parts of speech) and structured objects (sequences) and perform express operations on them without having to worry about how these “natural” concepts are actually represented in the machine. Also, the ability for routines to call themselves with no restrictions as found in the recursion techniques of LISP.

Our need to understand LISP took us down a very parenthesised road. This is a very brief introduction of what we saw in LISP.

What is LISP

Lisp is a programming language developed as a mathematical notation for computer programs, greatly influenced by the work of Alonzo Church's lambda calculus and become, pretty much, the programming language staple for artificial language research. Lisp derives its name from LIST Processing and it is no surprise that linked lists is one of LISP’s key data constructs. LISP provided a basis or became a genesis for significant concepts in early computer science thinking. LISP’s ability to type data objects instead of variables gives it the flexibility to provide native support for arranging data into a hierarchy based on subset relationship.

Linked lists are one of Lisp’s major data structures, and Lisp source is itself made up of lists. As a result, Lisp programs can manipulate source as a data structure, giving rise to both grammar parsing and even creating new syntax. The inter-changeability of source (formal grammar defining language) and data gives LISP its unique syntax. All source is written as s-expressions, or parenthesized lists. A call to a routine is written as a list with the operator's name first, and the arguments following; for instance, a function F that takes 2 arguments might be called using (f x y).


The biggest advantage LISP has over other languages such as C, C++, and PASCAL is due to the idea that LISP follows the philosophy that what's good for the language's designer is also good for the language's users. Consequently, the programmer, unlike in other languages, can add features to the language making it a self-hosting language. LISP tends to provide a more transparent map between ideas about how the program functions and its source. This is therefore ideal for situations where problems are partially specified and/or where problems whose nature is not fully understood at the outset. Approximation can be developed and refined interactively over time.

Also where a problem involves multiple representations of data from varying sources, LISP's flexible data abstraction system makes configuring robust systems simpler.

The Parentheses ( )

For people like me who was used to looking at C, Pascal, and even Fortran. LISP was initially confusing. Its syntax was nothing like I had seen before (perhaps with the exception for APL which was itself mathematically inspired and served as a executable notation for mathematical algorithms). Parentheses are the basic building blocks of LISP. All functions, operations, and scripts take place within parentheses. Complete functions have a matching number of open and closed parentheses.

When merging lists

(APPEND `((A B)(C D)))

Answer (A B C D)

Creates a function called ADDIT that takes two parameters x and y and adds them.

(DEFUN ADDIT (x y) (+ x y))

(ADDIT 3 4)
Answer 7

Creates a function for calculating powers

(defun expon (base powr)
(cond ((zerop powr) 1)
((evenp powr) (expon (* base base ) (truncate powr 2)))
(t (* base (expon (* base base) (truncate powr 2))))))

Saturday, March 6, 2010

Experiences That Are Quite Unreal

Sydney Morning Herald

Sunday June 28, 1992


Jack Dikian and Virtual Worlds

IT USUALLY takes years for a computer technology to go from the laboratory or R & D department to the mass market. Those lucky enough to experience a new technology in its infancy are generally only the well connected or the wealthy

An exhibition at the Powerhouse museum (Sydney) next month will allow the public to experience two exciting and quite recently developed technologies - virtual reality and the computerised transformation of images known as "morphing".

The exhibitions, called "Virtual Reality" and "Altered States", will run during the school holidays but the Powerhouse museum expects as many adults as children to attend.

The Powerhouse claims to be the first museum in the world to conduct an exhibition, albeit a temporary one, on virtual reality.

According to the museum's curator of mathematics and computing, Matthew Connell, the aim of the Powerhouse has always been to feature new technologies.

"We have a tradition of presenting new technologies to the Australian public," said Connell. "These are important technologies which will have enormous impact, and we want to be there from the very beginning."

The virtual-reality exhibition will be a hands-on experience - people wearing headsets and holding joysticks will interact in computerised "virtual"worlds.

There is a choice of two virtual-reality experiences - Dactyl Nightmare(prehistoric birds swoop on you from great heights as you avoid an opponent)and Capture the Flag (ambush your opponent and seize his flag before you get shot).

Each fantasy experience takes three minutes and about 120 people will be able to participate each day. The visuals of Dactyl Nightmare and Capture the Flag will be shown on television monitors for the benefit of those who, because of time limitations, aren't able to participate.

Connell is not thrilled by the content of the virtual-reality experiences, but says the most important thing is enabling people to experience the technology.

"Dactyl Nightmare and Capture the Flag are shoot-'em-up games - they're not as bad as some video games, but that was all that was available to us," he said. "We're more interested in showing people the technology than whether the content is ideal. For a permanent exhibition we'd present a much wider choice than video arcade narratives.

"A lot of people will be interested in virtual reality as a new experience, but we want to draw attention to the enormous potential of the technology: for example, the less-sensationalist possibilities in science, education, design," said Connell.

The Powerhouse was investigating the feasibility of a virtual-reality display and speaking to companies in the United States and Japan when it discovered a Melbourne company that had begun distributing virtual-reality systems.

The Virtual Reality Corporation, which formed earlier this year, has the only two commercial virtual-reality systems in Australia. They are aimed at the education market and were produced by W Industries in the United Kingdom -systems are already installed in some European and American clubs and retail stores.

The museum's director, Terence Measham, said the Powerhouse was keen to develop a permanent virtual-reality exhibition.

The other temporary exhibition, "Altered States", will focus on the popular technology "morphing", in which a computer seamlessly transforms one object on-screen into another. The technique was used in Michael Jackson's video clip Black and White, in the film Terminator 2, and is being used in some Australian television commercials.

The exhibition will feature two graphics simulations on Silicon Graphics workstations which are explored using a spaceball, or 3-D mouse. People will be able to fly over a fractal-generated landscape in a paper aeroplane, and walk through an architect's design of a building.

Jack Dikian, a futurist with Silicon Graphics, will be at the museum, conducting demonstrations and answering questions on computerised image transformation.

"We hope people gain an understanding of how interactive 3-D graphics can be used in the workplace, and that they develop an appreciation of what the technology can do for them," Dikian said.

He said that people seeing a simulation for the first time usually reacted with stunned silence. "Most people are struck by what they're seeing. You'd never expect to look down at a mountain as you fly over it. People often ask if they're watching a movie," he said.

"Virtual Reality" is on daily from next Saturday to Wednesday, July 8. It is recommended for children aged 10 and over. Bookings must be made in person on the day at the museum for a chance to participate. Twenty names will be drawn from a barrel each hour. "Altered States" is on daily from Monday, July 13, to Sunday, July 19, from 10 am to 4 pm.

Critical Principles In Establishing A Support Structure

Jack Dikian


Media Lab Pacific

June, 1984

Among the many services a typical Support Centre provides to its client base, perhaps the ability to maintain control over the many unresolved or pending tasks is .the most important. A typical Support Centre facilitating a medium sized computer supplier can handle hundreds of queries a day. The type and complexity of the queries can vary greatly. As platforms become more and more compatible, not only does the variety of tools and packages increase, but the source of those tools and packages become increasingly diverse. Good examples of this are apparent in the Unix and DOS environments. These days, both environments promote a great degree of compatibility; exhibit a large variety of readily available software solutions, as well as fostering the proliferation of independent software developers competing to sell the perfect accounting system, the fastest DBMS, and even the trickiest adventure game. All of this can of course be contrasted against a less open system such as the proprietary operating systems. Here, major tools and packages are often written in close collaboration with the original platform manufacture. Providing support in an open environment may in some cases require a Support Centre to be many things to many people. A well thought out support strategy aided by a comprehensive task tracking system can make the difference between an effective support unit and one that is pure hindrance to all parties concerned. This paper presents what I consider important when setting up a formal Support Centre in an open environment, as well providing some design ideas for a productive task tracking system.

1. Introduction

A Support Centre is usually that part of the overall EDP effort that attempts to answer queries and/or coordinates the resolution of problems that clients experience while using a particular system. The support effort, philosophy, and practice can span between two functionally varying extremes. At one end of this spectrum, the Support Centre and its personnel can be extremely specialised and thus attempt to provide the same sort of client support as that expected directly from back room technicians. On the other hand, the Support Centre may be setup such that it caters for a much broader, and hence more general client base. At Media-Lab Pacific a less technical support team is supported by a more rigorous system of call recording, problem escalation, task distribution, and follow up strategy. Factors which often determine the type of support that will be provided out of a formal Support Centre include the following considerations:

  • The variation products to be supported.
  • The stability of the target environment.
  • The standard of service expected from the support team.
  • The size of the EDP team from which support is provided.

2. The Degree of Product Variety

Open environments such as Unix cater for, and encourage the proliferation of standard non-proprietary technologies. The number and variety of available packages and utilities can be astronomical. My latest copy of Sun Microsystems’ Catalyst (catalogue of third party hardware/software SPARCware solutions) lists more than 2000 products in 22 very broad categories. Silicon Graphics boasts a heafty 700 page Applications Directory. At a different level, most Unix systems come to us with at least three file backup mechanisms, two editors, two command line interpreters, and a host of vendor added features. One particular manufacturer even provides two flavours of Unix running on the same machine at the same time.

Although much of this type of variety comes about from a genuine need for a particular feature, there is nevertheless sufficient overlap and a great deal of inherent flexibility to allow the client to use any utility based almost entirely on preference alone. Back at home, things are not too much easier either. The PC industry has never been in a stronger position, providing great performance for value; a host of industry standard plug ins, migration paths, and a world of software.

The wide range of products are often indicative of the large number of independent vendors, all committed to making their goods available on these platforms. Whilst a suite of products written for one proprietary environment may feature common menu structures, file layouts, control files, naming conventions, and even consistent documentation, a series of products supplied by different vendors in an open environment will often possess no underlying uniformity. Contrast for example DEC’s VMS operating system against Unix. VMS, like Unix parades a large number of layered products. However, unlike Unix, layered products under VMS all exhibit the same underlying design philosophy. Control keys always represent similar actions, help files always display similar layouts, and error messages always have the same consistent format.

Each product in an open environment will require the same high level of technical training before it can be properly supported. In such an environment, a generalised type Support Centre is most effective. Personnel in this centre may have an overall systems, analytical and communication skills, but may lack the specific specialised product knowledge. There are simply too many products for any one individual to know well. In such an environment, the Support Centre acts as an interface between the client and other more specialist EDP groups. How this interfaces is likely to work is closely linked with factors contributing to the overall style of Support Centre. For example, the overall size of the EDP group, the size of the client base, agreed turnaround commitments, and the sophistication of task tracking system will often determine the interface mechanism.

3. The Stability of the Target Environment

The stability of the typical environment that requires support is a very important factor in determining the type of support expected from a Support Centre. Site instability may be inherent within a certain client group or may transcend them. In an environment which has just gone through a major systems conversion, upgrade or simply taken on new responsibilities, it is typical that that site will experience a period of instability. On the other hand, a software house involved in developing systems around products that you are supporting will seem in a sense always unstable. In the later case, queries will often be raised reflecting the need for more detailed specifications, reporting faults which may or may not be associated with your product, and importantly, the reporting of legitimate, but low level anomalies which get picked up due to the nature of this sort of work.

Both of these scenarios need to be addressed. These support requirements will inevitably exist in both open and proprietary environments. However, in an open environment, not only are there many more independent groups developing systems, but often, these groups will know as much about your product as your Support Centre personnel. This is especially true if the Support Centre is of a generalised type. Clients experiencing significant downtime due to various reasons including conversion processes, come closest to justifying the need to contact back room staff directly. It is also this very desire that raises the many concerns for the quality of support. Clients more often than not, always prefer to discuss their problems with back room personnel directly. However, there are just as many important arguments for clients to continue to address their problems through a centralised Support Centre. Many of these arguments are to do with a supplier providing a consistent level of support, as opposed to a see-sawing effort depending on the availability of key personnel (See figure 1). Figure 1 illustrates how the quality of support (*) can vary between two great extremes when the Support Centre is basing their support effort on key back room personnel. When these people are available, the support effort is at its peak. However, when they are unavailable, support effort is reduced to a minimum. The use of a more generalised support team (-) allows the Support team to provide a much more consistent support effort. It is neither as good as the back room personnel, nor as bad when they are not available. In time, this quality will rise. Providing consistent support, with an agreed service level come about most effectively through the implementation of service level agreements between yourself and the client base. The section discussing the standard of service expectation will further detail the implementation of service level agreements.

Fig. 1

In the situation where a client is going through a major conversion process, or where a major upgrade is to be released, the generalised Support Centre should be supplemented by back room technicians rather than be abandoned. The client should be encouraged to schedule the conversion process, as well as assisted in associated areas such as risk analysis, resource allocation, and contingency planning. Both the client and the supplier will only then really appreciate each others requirements. This liaison process will allow the Support Centre to prepare more adequately for this situation. Without this sort of preparation, the support personnel are, at best, most likely to allocate the highest possible priority available to them before escalating the query to a pool of back room personnel. The problem with this approach is of course that there may well be any number of such high priority requests already outstanding. Some suppliers nominate certain individuals to be responsible for the support of one or more clients. Account managers are usually very effective in providing a personalised style of support. They can become acquainted with the specific needs of the client, as well as develop an understanding for the longer term directions of the organisation. These people also represent the supplier and its resources. The negative aspects of this approach however are significant in an open environment. The main problem is once again availability. The greater the dependence on the one account representative, the more exposed both parties become.

Account managers also tend to have strong consulting, negotiating, or managerial skills. These qualities are very important when dealing with sites that feel undersold. At the end of the day however, hands on representation will still be required. Problems need not only be understood, but fixed in a timely manner.

4. The Standard of Service Expected from the Support Team

Often, the effectiveness of a Support Centre is erroneously measured by the quality of on the spot advice the support personnel can provide. For example, there is always a perception that a particular organisation has a good support operation if clients constantly receive informative advice immediately. On the other hand, giving the client a reference number with the promise that an expert will attend to their call as soon as possible raises, in some peoples’ minds, a certain amount of cynicism. There is simply no formal framework by which to gauge the effectiveness of the support in non-subjective terms. Questions like "Why can’t we talk to this expert direct...?", "why do we need to explain this problem all over again?" and so on are asked, and asked of the wrong people. This concern is accentuated when the overhead costs of maintaining the support effort are passed on to the client base. Soon, some clients will attempt to contact back room personnel directly, avoiding the so called front line. Clients who judge a Support Centre ineffective, fairly or otherwise will always attempt to bypass formal support structures. In general, clients believe that back room personnel are the ones who really understand the problem; they know the system and have the facilities to fix it. Everyone else, including the Support Centre are nothing more than "go betweens." To some extent, there is a lot of truth in this belief. Support consultants, specially in a help desk centre do not have the luxury to see the problem for themselves. They can only react to what the client thinks is seeing.

Often, if the Support Centre can’t resolve a problem over the phone, they are forced to escalate the task to someone who can. Back room personnel may be so familiar with particular anomalies that they will save the client the bother of describing peripheral, and in retrospect, unnecessary detail. Also, where a support consultant may tackle a new query by first examining a wide range of possible causes, a back room technical person, faced with the same task may grasp the kernel of the problem much quicker. The other side of the coin holds a different picture. It is also true that most back room guys do not want to be interrupted by users. Back room personnel can handle direct contacts in various, and in some cases undesirable ways. Perhaps the three most common reactions I have seen are:

They may refer the problem back to the Support Centre and hang up in the clients ear. This, as it turns out is probably the best course of action in the long run.

Secondly, they may promise the client prompt resolution knowing full well that they will neither have the time nor the inclination to carry it through.

Finally, they may well resolve the problem in a timely manner, but fail to inform the client, or their peers of the solution.

Back room personnel are never hired based on their diplomacy, communication, or even business skills, most of these people will call a spade a spade. This is regardless of who the caller may be and the sort of effort the sales team expended to secure them.

Back room personnel, the development team, systems managers, operators, DBA’s etc are highly paid professionals who, without stating the obvious, have a job to do. It’s simply not as if they are waiting around idle for someone to ring them with a problem. Often they are working against tight schedules, with priorities not including impromptu client requests. Often, what starts off as a very brief interruption may eventually result in a great deal of wasted time and resources. In the event that a problem has been accepted directly in such an environment, there is no real guarantee for effective follow up, no framework for providing a realistic turnaround time, or even a rudimentary concept of ownership.

So what is a fair expectation of a Support Centre, and what can a supplier do in terms of its support policy? The best way to avoid unreasonable client expectation is to tell them exactly what you will, and will not do. If the Support Centre is manned between the hours of 8:30am and 6:00pm, then the client should be made very aware that support is not available outside these hours. If the Support Centre is promising a maximum turnaround time of 3 hours for critical problems, then clients should be sold the support service based on this condition. With the same token, published support hours are required to be adhered to by the support personnel.

A support facility between 8:30am and 6:00pm means just that, and does not mean 8:45am to 6:15pm. Also, a promise of a 3 hour turnaround means that if an answer is not found within that time flame, then the client is informed, and a suitable alternative arrangement is made. The creation and regular maintenance of a standard service level agreement is not only a very effective method of making your position clear in terms of the support delivery, but it is also a vehicle by which the client can use to request certain specific functions. The implications of the service level agreement will drive the practice and policy of the support personnel. Once the Support Centre is comfortable with this agreement, every new client likely to use your support facility should understand and accept the terms and conditions of the agreement. In the event that a particular client has specific requirements outside the scope of the standard service level agreement, then a new agreement should be forged before formal support commences.

The new service level should be such that both parties feel comfortable with. It is no use for example the client requesting call back on reported faults within an hour when the Support Centre averages 2 day turnaround time. Ultimately, an attitude where the user pays should be employed. If a client has a need for 24 hour support, and your Support Centre only provides an 18 hour window, then the idea that the client pay for facilitating the expansion (should you agree) of the support window should not be discarded lightly. It is also important that the service level agreement is structured such that it complements the original maintenance or service warranty contract. The sort of elements in a typical service level agreement should include:

  • Support Centre hours.
  • Method of priority allocation.
  • The meaning of priorities and corresponding actions.
  • Escalation mechanism, and responsibility lines.
  • Forms of expected documentation.
  • Emergency arrangements.
  • Turnaround times for various types of situations.
  • Contact name nomination guidelines.
  • Support Centre responsibilities.
  • Problem status reporting procedures.

The presence of such a document takes away any misconceptions of the Support Centre’s role. It clearly identifies what the Support Centre will do, and how it will do it. Importantly, clients can compare how the Support Centre is performing against how they have formally committed to perform. Anomalies can be raised and resolution sought at the appropriate business level. This type of structure enforces accountability at all levels. What this understanding also does is throw back some responsibility on to the user of the Support Centre. In the same way that the client can highlight difficulties with the Support Centre, the Support Centre itself can rightly object to providing a support facility if the client is not upholding their end of the bargain.

For example, if the client has been asked to document a particular problem in accordance with the service level procedures, and have failed to do so, then the Support Centre can legitimately hold that query pending until the relevant documentation is supplied. The Size of the EDP Team from which Support is Provided In a very small EDP team comprising say of 15 members or less, it can be argued that there isn’t a large enough infrastructure to support a dedicated support group. However, as the EDP group grows, and the overall EDP effort divides into specific speciality areas such as R&D, business consulting, operations, and systems delivery, it becomes more and more apparent that a support type team is necessary. In some cases, this support team is a misnomer, and what the group really needs is an office administrator/telephonist/goofier. However, as the client base grows and their requirements become more sophisticated, a single contact point within the EDP group becomes unavoidable. This is the support team. Not only does the support team provide fault diagnostics and rectification, but also a host of many other functions.

For example, the support team can coordinate and follow up the resolution of queries within the EDP group. The Support Centre can act as an interface between the client and the supplier, as well as interface between the many sub groups within the EDP group (See Figure 2). Problem prioritisation, logging, and reporting is also something typically handled without a Support Centre. These functions help glue the overall EDP effort as well as streamline the many client requests. Importantly they free the other groups from continual client interruptions, and channel the filtered requests to the most appropriate people. The client on the other hand sees a single consistent face who is prepared to accept ownership of the problem until it is resolved.

In order for the Support Centre to maintain control over the many unresolved tasks, and also provide efficient call reporting and statistics facilities, a sophisticated task tracking or logging system is indispensable. The task tracking system should not be confused with a general task scheduling, or even an accounting system. Although both a scheduling and account charging system can be implemented underneath the task tracking system, in general, these modules should exist independently. The task tracking system should however possess the following features:

A multiuser system with the ability to differentiate between user groups in order to provide in context displays and data update restrictions.

An inter/intra office E-mail and fax interface system.

The ability to accept task priority allocations, and prompt the user with the appropriate action based on a setup database.

The ability to accept and or automatically allocate expected completion times for tasks based on a number of criteria such as priority, client expectation, task type and client status.

The ability to accept historical notes and provide online query reporting based on client, task type, task status or chronological order.

The overall system should be fast enough to service a real interactive session. Typically, queries and actions should be generated at speeds that match the telephone conversation.

The system should be sitting on top of a user maintained database that provides such things as valid contact names, site information, product information, release compatibility, release schedules, inventory control, technical notes and online manuals. An escalation system should exist that is based on task urgency, potential client exposure, allocated priority, and completion time blow outs. The escalation mechanism should be such that it automatically raises the priority allocation, warns the support team, and delivers the appropriate messaging to the support supervisor. The system should allow the creation of ad hoc query and reporting facilities by the user. This is opposed to reports that are run periodically. Periodic report should provide both the user and the client base with various statistical, and managerial information. This should include outstanding open queries, queries of a certain type, queries logged within a period of time, query history and other charge information. Tasks should be allocated to individuals and or groups, with the guarantee that all unresolved tasks have a single owner. The owner may change during the resolution cycle, but it must always have an owner. When tasks are reallocated, the person receiving the task should be made aware via a formal and agreed mechanism.

A facility should exist to reopen closed calls, or alternatively, clone previous calls for subsequent alteration. This allows the support consultant to quickly log calls based on previous facts.

The system should allocate unique task reference numbers that can be used by both the client and within the EDP group.

A number of task status codes should be catered for to reflect the position any one task is at. For example, a task may be pending, closed, completed or current.

Action codes should also be employed along with a more descriptive comment to indicate the sort of work that has, or will take place for any particular query. For example, the support team may indicate that the query has been transferred to development, the development team may indicate that they are testing etc.

A system of query categorising should be catered for such that each query can be placed in a particular class of problem. For example, the query may pertain to network errors, inoperative terminals, application errors, systems errors etc. This will assist in reconciling the problem areas and thus put in place longer term solutions rather than simply fixing the problem at hand. It should also be said that even the most sophisticated task tracking systems become ineffectual when either the system is not accepted by the users, or when there isn’t enough motivation to use them. The system has to be used by all parties concerned, or none. Once a commitment is made to use such a system, management should ensure that all members comply. Equally, nagging difficulties identified by the users should not be discarded. The biggest problem with getting such systems accepted by users is the obvious fact that it might take a few minutes to resolve a problem, but an equal amount of time to register it. It should be noted that much of the benefits of these systems are long term ones and therefore may not always be appreciated in the short term.

The system should also be used in an on-line manner and queries logged into the system as they are raised.

An off-line system will result in catch up games played at the end of the day in order to register the days queries. This has two main disadvantages. The first is that retrospective entries will be rushed and can be erroneous. The second is the very real possibility that certain requests do not get processed until the task is recorded. This particular problem is especially ominous when the service level agreement promises a few hour turnaround time for very high priority tasks.

6. Conclusion

The two most overwhelming factors which go hand in hand when an organization is looking at providing an effective support effort is the introduction of a well thought out service level agreement, and the implementation of a task tracking system. The scope of the service level agreement, and the functionality of the tracking system can evolve over a period of time, however, it is extremely important that a certain amount of initial planning takes place. It is important for example that prospective clients understand, and accept the manner in which support will be delivered. New services and conditions can be amended in time, however, the basic principles of working within an agreed frame work, and providing a measurable standard of service should be a major initial goal. The task tracking system can also start small. The first version may be nothing more than a hand full of shell scripts that allow call recording, searching, and reporting. Once again, the system should be designed such that it can grow with the users needs. It should be a system that the user needs and drives unlike many large systems available these days which force the user to change there working methods.