And of course he wanted it all tied together on a network.
About that time (1989) I was experimenting with RDBMS software (R-Base) to put together a simple system for recording student assignments and scores. The college had installed a couple of local area networks (Netware 2.0a on 286’s, ARCNET and IBM baseband), and was starting the process of replacing an IBM System36 and RPG with Netware, DOS and Ansco Paradox 2.0. He saw my prototype and offered me a move from teaching to full time IT – in a department of one. Me.
So I built a shiny new campus-wide routed ARCNETnetwork, built a couple of Netware 2.0a servers, and started writing the software that would execute his vision using the multi-user DOS-based Paradox 3.0 as the RDBMS development platform.
Within a few years we had a fully networked campus with nearly every computer and lab on the ARCNET network, multiple Novell servers, and real-time relational database software that covered most of the administrative and academic computing for the college.
I learned the fundamentals of managing relational data, normalization, foreign keys, indexes, etc. The college ended up with desktop software that managed student registration, fees, payments; quiz, assignment and test scores; course grades and academic transcripts. By the early ’90’s, students could walk up to specially configured PC’s and any time and look up their grades and see exactly what they needed to do to complete a course, program, degree, certificate and graduate.
Everything was multi-user and real-time. If an instructor entered a test score, the student would see the score in real time. If the score was the final score needed to complete a credit, course or entire program, the student would see the final credit, course or program transcript seconds later.
No batch jobs. All DOS based and Netware networked.
One of the barriers in the pre-386 days was DOS’s inability to multitask. That made some aspects of the software pretty difficult to use, and any task that required significant compute could not be backgrounded. The meant for example, that a registrar who needed to run a report for a student would have their PC tied up waiting for the report to complete. That slowed down the registration process significantly. I scratched my head a bit – multitasking OS’s were not readily available. Quarterdeck DESKview and QEMM were fairly usable but affected desktop performance. Instead I came up with a novel solution that allowed background processing without affecting the performance of the users desktop.
I created a small multi-user relational database that acted as a job queue. When the real-time users executed functions that would likely take more than a couple of seconds, the application would insert the function & parameters into the ‘job’ database. A rack of old 286’s were left running and logged into an app that would scan the job database. These ‘workers’ would scan the database, and if a record was unlocked, would lock the record, execute the function, return the results to either the student record RDBMS, a temporary table, or directly to the Registrar’s printer, then unlock and archive job record. Then during peak processing times (registration week) I simply dusted off more old 286’s and net-booted them into the worker app, where they would share the background processing load. That made the whole thing somewhat scalable.
I think it was called ‘Distributed Network Computing’ or something like that. But I used RDBMS record locks as the semaphore and database records as the messaging path.
After the student records database was roughed in and working, the President had me look at the purchasing system. We were using an archaic green-screen app hosted on a mainframe run by a service provider. The app was obviously ported from punch cards – the green screen input had to be column aligned, the results of a ‘submit’ would show up minutes or hours later, and any errors caused an entire batch to be rejected.
And of course all that did was update the chart of accounts. The actual PO’s were done on a typewriter.
Brutal, considering what we had on the student records side.
We took a look at the ‘modern’ version of that providers software – a PC application that put the 80 column, position sensitive batch processing on a DOS green screen with a modem to submit the job to the mainframe. Errors were returned the next time you dialed up.
Brutal, considering what we had on the student records side.
The President asked my how long it would take to rough in something using Paradox RDBMS. I committed to a prototype in 3 weeks. In a handful of months we had a fully relational multi-user real-time purchase order and account management system where departments could key in their own PO’s, accounting could approve and print them, chart of accounts and budgets would automatically be encumbered, and the service providers mainframe would be updated at the end of the day. Departments could look up their budget any time and see the balance and everything transaction affecting their accounts.
And of course the President had a small app that let him monitor budgets real-time, showing recent encumbrances bubbled to the top and highlighted red. He watched the budget like a hawk.
I eventually integrated our Financial Aid software – a commercial DBase based package. That integration allowed us to automatically determine how much of each students financial aid was surplus to their tuition and fees and automatically cut financial aid checks. Of course the first time we did the automatic check printing, we messed it up.
We also struggled with room scheduling, so I built a really simple room scheduling application using Paradox. The core of the application was a single table with building, room and 10-minute time block as a composite primary key. Checking room availability was a simple query, and Paradox’s built-in key and record management prevented duplicate events.
By 1992-1993 I had automated most mundane paper-generating process and several data-entry jobs – which we eliminated through attrition.