COBOL grouse

I dug out some of my old technical books from storage, looking for blog fodder. One of them was the book I really learned COBOL from, Greg Lupfer's DTSS COBOL: Introduction (1974), published by Dartmouth College's Kiewit Computation Center (DTSS is Dartmouth Time-Sharing System, and was an online environment that shared roots with Multics). There was a shelfload of copies of this book available to new programmers like me at Greg and Gary's consultancy in the early 1980s. For the most part, the presentation is no-nonsense, focusing on the features of COBOL 68 that you'd actually use to write business applications (with the exception of the Report Writer module, which has always been no more than a historical curiosity to me). The book is set throughout in a Courier-like font, and it looks like it was laid out with RUNOFF.

Using the example of an order entry system for a consumer audio store in Minnesota (with customers like R. Zimmerman from Hibbing!), Greg walks you through how an indexed-sequential file works, he explains figurative constants and the REDEFINES clause, and he touches on a few points of good programming practice. Early on is this deadpan gem:

The first program to be described is ORDER11. This program will accomplish the first step described above, which is to create a working data record that contains three additional fields used as the record progresses through the order edit module. The functions of these three fields are defined in the comments included in the IDENTIFICATION DIVISION of the program.

The name ORDER11, which seems to a rather unimaginative name for a program, is the result of an overall file naming convention that is used throughout the system described in this text.

Greg spells out a convention for naming source, object, transaction data, and master files within the constraints of eight (8) alphanumeric characters and no extensions. He then expostulates:

Most COBOL application systems use dozens of programs and files, so a consistent file naming convention is essential, and is to be preferred over assigning "meaningful" names to the files. These meaningful names often have meaning only to the programmer who wrote them. One actual system of seven programs used the names DOC, HAPPY, BASHFUL, SNEEZY, GRUMPY, SLEEPY, and DOPEY, and the programmer was not Ms. White. Any experienced programmer can probably recall similar instances of absurd names for programs. (pp. 22-23)

Greg didn't always follow his own advice. There was a legendary one-off that he wrote for a customer to scrub out unwanted control characters and other fluff. As the story goes, he named it REMOSHIT.

Return of the regex mystery

The little one-off function that I wrote to extract the file name from a URL still continues to baffle. Rekha, in the course of reviewing some other code and functionality, threw a random string of letters (no punctuation) at it, which caused the browser's script engine to time out. I rewrote the code somewhat, but even this version takes about 30 seconds to complete, when given a string like "asdfghjklasdfghjklasdfghjkl":

var URL_REGEX = /^(http:\/\/)?(\w+\.?)*client\.org(.*)$/i;

stripUrlPrefix = function (url) {
    var regex = new RegExp(URL_REGEX);
    var result = jQuery.trim(url);
    var matches = regex.exec(result);
    if (matches) {
        return matches[3];
    } else {
        return result;
    }
}

More songs about buildings and slugs

I wrote about slugs as naming technology some weeks ago. It seems that in the direct mail industry the term has a slightly different meaning. And somewhere out there, if there is justice, there's a requirements analyst that got slugged.

Carrying on for Adm. Hopper

Via The Code Project, Emily Goligowski surveys five programs designed to give girls and women an extra boost in technology training.

In 2008, girls made up just 17% of Advanced Placement test takers in computer science (the lowest percentage of any subject) and held less than 20% of CS degrees.

Too bad about the annoying widgets salted into the text of Mashable's pages; also, the demo for this article apparently skews female, so the ads are all about shoes.

There's a plugin for that

I recently went through this exercise: for a form submitted by Ajax, disable all the controls on the form until the Ajax update completes. The code to perform the disabling is nothing particularly complicated:

CLIENT.Utilities.disableJQueryDialog = function (jq) {
    try {
        $(":input", jq).attr("disabled", "disabled");
        //NOTES: Disabling other clickable elements (<a>, <span>, etc.)
        //is the responsibility of the specific resource overlay.
    } catch (e) {
        CLIENT.Utilities.postWarnMessage('', 'Utilities.js disableJQueryDialog()', e);
    }
};

Call this function with anything that can be a jQuery context, and all the one-line text boxes, dropdowns, checkboxes, and radio buttons in that context are disabled. As the notes indicate, we have other UI elements that the user can interact with (like hyperlinks), so I worked out a simple pattern so that a dialog overlay can register a callback function to disable other HTML elements. I also used this callback to disappear any popups from the date picker plugin and to remove TinyMCEs attached to <textarea>s.

Well, it turns out that there is a jQuery plugin that will do most of what I needed to do, and throw up a "Loading..." message as well, according to Dino Esposito. If I have some extra time this afternoon I'm going to check out the BlockUI plugin for jQuery.