Thimbles & Care

I was thinking about viewing SPOOL files, and I thought I’d share the story of how *UTQA came to be written.

COM-PLETE comes with a SPOOL utility, *UQ. Some time around 1990 or so, we got a new release of COM-PLETE that significantly changed the appearance of the output of the A subcommand, the one that shows active jobs. Lots and lots of developers were complaining, with some reason since the old version had showed drained and idle initiators while the new one doesn’t. We had recently installed the first version of Natural Process (since renamed Entire System Server) and I was figuring out what could be done with it. As I read about the SPOOL-related views, I thought, “I could write a simple program that replicated the old behavior of *UQ’s A screen.” So I did. I gave it what I thought was the obvious name, *UTQA, since it was a UT utility that replicated the old *UQ A subcommand. I showed it to John Camden and he wanted it expanded to replicate all the functionality of *UQ. I didn’t see much point in that, since everything else in *UQ still worked like before. However, Marshall Thomason, our DBA at the time, decided to run with it, so he wrote the rest of this application. A few other people have maintained it since then; in particular, Jim Bullock added support for sending output to “green print” a few years ago.

So that’s the story. If you’re wondering what I use, I usually use Natural ISPF. I’ll go to *UTQA when I want to see idle or drained initiators, or to use the green print function. I still use *UQ to scan SYSLOG, or for its non-SPOOL functionality.

The past few days we’ve had folks from the Kuali Foundation here giving us an overview of their projects, so I thought I’d post my reactions.

I think the Kuali business model—developing open source software in a consortium of similar organizations—makes the most sense for the University. Our current model of developing everything on our own seems less and less sustainable as time goes by; even if we were to continue developing what we’ve already done indefinitely we’d want to try to find other partner institutions to share development efforts with eventually. I think it would be easier and cheaper to convert to something open source like Kuali rather than a vendor product where we would have to rely on their documentation rather than being able to look at the source code to see what’s actually going on. Also, as a member of a consortium we would have more influence on product directions and features than as mere customers of a vendor. The only real advantage of going with a vendor from a management perspective is you have someone else to blame when things go wrong.

Given that the business model seems good, the only question is how is the quality of the product. Now, it’s hard to judge that just on presentations and demos, but they seem to have done a reasonably good job of designing and implementing their systems. So if it were up to me, I’d say we should plan to convert to Kuali.