A RESOURCE CONTROL AND MONITORING PROGRAM

Published in FIRST ANNUAL TAFE COMPUTER CONFERENCE 1984
by CHRIS MORRIS, Faculty of MECHANICAL ENGINEERING

ABSTRACT

Briefly describes a program written on the VAX computer system, to control and monitor the use of the VAX computer resources at Sydney Institute of Technology.

While the program is written specifically for Sydney Technical College, the possibilities for application of this type of program in other colleges is extensive.

PREAMBLE

At Sydney Institute of Technology there are two VAX 11760 that are connected to seven rooms each containing fifteen terminals and a printer.  Prior to 1984 allocation of these rooms was initially made by faculties making bids and bargains at meetings which were hold early in each semester. As classes were canceled or initiated during the semester, time booked was released or time free was booked. The computer department managed these processes, and kept it's records on a white board in Building E.

In 1984 the computer user group agreed to manage these functions, and the task of chief arbitrator - record keeper was delegated to me. Several changes to procedure were made.

  1. The Initial allocations were made in the last days of the semester preceding that for which the bookings were required.
  2. Alterations during semester were made by phoning the record keeper, who was available for half an hour on four days of each week.
This arrangement was inferior to the previous method because of the inconvenience of contacting the record keeper, and because telephone communication does not permit graphic display of available time slots.  To solve this problem, I wrote a programme that would be permanently available to VAX users, that would maintain a record of bookings.

DESIGN CONSIDERATIONS

  1. The program should contain a complete record of all week day bookings for the 18 (eighteen) weeks of a semester.
  2. Any user (i.e. teacher) should be able to access the program at any time, to establish whether his School had any particular terminal room booked for any time during the semester.
  3. A school representative should be able to book or cancel a terminal room for his school but should not be able to inadvertently interfere with the bookings made by other schools.
  4. The program should be easy to use, and it should be invulnerable to anything but a determined effort to corrupt it.
DETAILS
  1. The program is written in PASCAL and occupies about 55 blocks.   The compiled version is about 40 blocks.
  2. The program is executed by logging in to the account "SEMESTER1" or "SEMESTER2" in the appropriate Semester on the Base Computer and then entering the command "RUN BOOK"
  3. The number of schools is limited to 24 (the free letters of the alphabet)
  4. The number of rooms that can be booked is not restricted (except by practical considerations).
  5. The number of hours that can be booked each day is limited to 14. (i.e. 28 half-hour slots).                     1
  6. For operational simplicity, the weeks that can be booked are the normal 18 weeks of semester.
  7. To avoid deadlock situations, only one user can access the file at any one time. If a second user attempts to use a program, then the program will fail for the second user on a file protection fault.
  8. There is a menu with six options. The first three options are for inspection of bookings. The fourth is to make or cancel a booking. The fifth prepares a file from which hard copy of the bookings may be prepared for a semester. The sixth terminates the program.
  9. All options except the fourth are available to the casual user. The fourth option requires a password that is entrusted to the school representative, and permits the representative to either book time for his school, or release free time held by his school.
  10. The system is fail safe.   If information is incorrectly entered then the program will either request its re-entry, or crash. The integrity of the database file will not he corrupted.
  11. Execution can be interrupted (with CTRL C)
  12. Changing of passwords, room names, school names, or identification codes can only be achieved at program level.
  13. Since only a compiled program is held in accounts SEMESTER1 and SEMESTER2 these programs cannot he altered by any user. The program is not suitable for general distribution to other than Pascal programmers having full documentation.
  14. In operation, the program maintains a file (called SEMESTER.DAT) that contains a (coded ) record of bookings. Menu option five creates a file (named TIMETABLE.DAT) that may be printed.


CONCLUSION

The program has been operational since April 1984, and in this time has failed once (due to corruption of the main program). Recovery was achieved the next day with no data losses.

General opinions of the computer users group is that the program fulfills its purpose effectively, and that it is user friendly.   At the request of J. McSweeney the program has had a statistical package added, and a statistical analysis of bookings is available.

It should be possible to modify the program so that it would check (in real time) whether bookings made were being :utilized. This task would require a not inconsiderable programing effort, and perhaps access to a higher priority account.

back to index