IT@UT

An Informal History of the UT Austin Tech Community

User Tools

Site Tools


define

*DEFINE

The original accounting system used by the central administrative offices was called *ACTION. Only accounting could really make updates in *ACTION; departments typically managed their accounts by hand or in PC spreadsheets, and then submitted paper forms to update the official University records. Data Processing recognized a need and developed an application, *DACCT, that allowed departments to manage their accounts on the mainframe. John Wheat was the principle developer of *DACCT. *DACCT was completely separate from *ACTION, but it made it easier to submit update requests and provided other features like reconciliation with the official University records.

*DEFINE started out as *DACCT2, a rewrite of *DACCT in (still in beta) version 2 of Natural. John Wheat didn’t like the name “*DACCT2” and kept trying to come up with something snazzier. At one point he complained to John Camden about how hard it was to come up with names starting “DA”, and John Camden suggested he look for a new prefix for the new application. A few days later John Wheat arrived at work very excited and announced to the team that he finally had a great name for the new application: the DEpartmental Financial Information NEtwork, or *DEFINE. His vision, which was eventually realized, was that it would provide a one-stop application for departmental staff dealing with University business that had financial implications.

The first version of *DEFINE still had its own files and wasn’t considered official University records. In the early 1990's, accounting took over responsibility for *DEFINE and merged it with *ACTION to create a single application using a single set of Adabas files. The *DEFINE name was retained because that’s what everybody outside accounting was used to using.

< insert stories here about bring up DEFINE >

*DEFINE is a menu-driven application. Users navigate within the system by entering 3-byte menu codes, called commands.

In the early days post-implementation, the programmers were finding and fixing bugs throughout the day. Each time they moved a bug fix to production and recataloged the code, users would get kicked out of the screen they were working on. This caused many complaints and created distrust about the reliability of the system. To solve this problem, the DEFINE developers agreed to limit code changes in production to specific time frames. These were called DEFINE releases. During a DEFINE release, the DPUSER star command was redirected to point to DEBETA, so users could work seamlessly while the production code was recatted. This procedure still exists in 2015.

Tales from the Early Days of DEFINE

Before *ACTION and *DEFINE merged, one of the more important processes was reconciling *DEFINE transactions with official *ACTION transactions. (This was basically the same thing you do when you reconcile your checkbook with the bank statement.) We (the *DEFINE team) developed a batch job that found matching transactions on the two files and marked the *DEFINE ones as reconciled. Housing and Food had an issue, though: every student that had a dorm room had to make a $50 deposit, and they really didn’t want to go to the trouble to make sure that, say, Suzy Q’s transaction was matched exactly and not to Jimmy K’s, they just wanted to make sure that the total number of deposits was the same on both files. They asked to be allowed to develop their own batch reconciliation job, that would start by bundling up big groups of these transactions, matching the groups, and then unbundling them to update the *DEFINE files. They were given permission, and developed the programs necessary, but before putting them in production we had a walk thru of the code. During the walk thru I (cgp) noted that there was no code in the unbundling/update program that verified that transactions being updated were the ones initially bundled. Hugh Phillips, the Housing and Food programmer, insisted that there was no way they wouldn’t be and the additional checks weren’t necessary. Sure enough, the first time it was run in production things went wrong and it incorrectly updated transactions all over the files. Sheila Ochner had to spend two days repairing the *DEFINE files.

Immediately post-release, all the developers took turns staffing a hotline for bug reports in DEFINE. One day when Laurie Mackey was working the hotline, she received a call from a frantic user.

“I accidentally approved a document, but I shouldn't have!” said the user. “So I unplugged my computer to stop it!”

“Next time,” replied Laurie, “you can just crimp the cord.”

define.txt · Last modified: 2015/03/02 17:14 by curtis