1. Introduction

Since the introduction of laser printers for student use (which have a higher maintenance cost that dot matrix, and are higher quality and hence more attractive to use) and access to lots of (printable) information via the web the cost of providing printer services for all students in the School became very significant.

In order to kurb the use of the laser printers, a print quotaing system was introduced for the start of 1996. The aim of this system was to provide adequate resources for students to complete their assignment work, but still discourage printing of excessive non-course related material.

It was also decided to allow students to purchase extra pages of printing at approximately cost price so they could print other meterial if they wished.

The basic approach is to assign each student an allocation based on the subjects that they are enrolled in. Once they have printed more pages than this allocation, their right to print is revoked until they purchase more pages.

Chapter two of this document gives an overview of how the printer quotaing system works, and subsequent chapters describe it in great detail. Appendix A gives a run down of the actual effect this will have on a normal student within the school.

The rest of this chapter is devoted to discussing the problems with the first implementation of the quotaing system and how the current second version approaches them.

1.1 The first attempt

1.1 The first attempt

The current implementation of the print quotating system is our second attempt. The first attempt, which ran for one year, showed up several flaws in the initial design, and it is worth noting these flaws as they highlight several important aspects of the system.

1. The first implementation recorded printer usage by user name. This seemed a natural thing to do, until we remembered that users sometime change their username. A more permanent identifier was needed, so the current system records all usage etc. by user id.

2. The first implementation determined page allocation for each session based on class membership from time to time. This is only sensible if class membership is stable throughout the whole session. While that is the case for the majority if students, there is a significant minority who change their class membership during session, and this approach did not work at all well for them.

   The idea of basing page allocation on class membership from time to time caame from the very successful usage of class membership to determine disc quotas and booking privileges. However these resources --- disc space and booking rights -- are not cummulative, so there is no problem with them being reassessed from moment to moment (or day to day). Printer page allocation (and modem connect time allocation) are cummulative, so it is important never to take away an amount that has already been given.

3. In the first implementation there was no way give easily give someone a personal extra allocation. It was possible to record purchases, but as purchases carry over from session to session, while allocations do not, that mechanism could not be pushed into service. The current system provides ad hoc allocations to provide for this very occasional, but still necessary, need.

While each of these problems was dealt with in some way in the first year, the solutions were not designed into the system, and so were imperfect. The current system definately benefitted from the experience of the first year.

1.2 Significant aspects of the second version

This section should possible go in the next chapter, the overview, but it can stay here for now.

This section discusses an assortment of interesting features of the printing control system, particularly features which distinguish it from the first version. It is an tour of the implementation rather than an overview of the design.

1.2.1 Audit Trail

The only history info that the first implementation kept was the printer logs. This was very useful for justifying usage counts, but did not help in explaining allocation -- but then the first implementation didn't really acknowledge the possibility of changing allocations.

The current implementation keeps, for each user, a trail of all changes in their status; either allocation changes, usage changes, or purchases. This information is stored in one file per usage (file named after the uid of the user) and is used as the authoritative source of information about the user. When the system needs to determine a users allocation and usage, it parses this file and calculates it.

Some summary information is kept, such as the current allocation for each user, but this is treated as advisory only and not authoritative.

As mentioned, the audit trails, or history files, are kept in files named after the uid of the particular user (in ASCII decimal). These in turn are stored in directories named for the last digit of the uid, and these are stored in the `history' directory in the directory for the particular kind of printer in question.

1.2.2 Stages Of Processing

As it is always possible for something to go wrong when processing data, such as running out of disc space, or a machine crashing, some care has been taken to make sure that no data will get lost or multiply processed when processing the printer logs.

There are five stages in processing the logs. Each one of these is restartable (incase something goes wrong during processing) and there is a single, atomic, transaction needed to go from one to the next.

These stages are:

Centralising

This involves copying the logs from the various printer spool directories into the central directory for printers of that type.

Moving

This involves moving the printer logs from the central directory to a of files being worked on. This has to be separate from Centralising as the Centralising process is asynchronous with the othe four stages.

Summarising

This involves parsing the logs and generating a usage summary for each user. This is kept in a similar format to what will eventually go into the history files, but is kept separate at this stage.

Updating

This involves copying the summaries into the history files. For each user there is a small window for error if there is a failure between updating the history file and unlinking the intermediate file for that user.

Archiving

After the histories have been updated the logs that were used are merge and archived.