Back when the earth was young and I made a living writing Fortran, SAS, and Cobol code (in order of personal preference) I learned a technique called “pseudo-conversational” coding, well-adapted to the IDMS-DC programming environment at my place of employment.

Pseudo-conversational code inverts the intuitive sequence of events. The final event of a pseudo-conversational program displays a screen; then the program terminates. No program is running while the user interacts with the 327x display terminal.

When the user presses the Enter key, that initiates execution of a new program whose first step is to read the screen contents, process them, present a new screen, and terminate. Hidden codes in each output screen determine which module to execute next; more hidden codes are used for parameter passing. Pseudo-conversational coding is handy because the CPU doesn’t waste any cycles while those pesky end-users decide what to input.

It also should sound familiar – the World Wide Web works the same way. So except for minor details like the difference between designing highly graphical pages and green-on-black character-mode screens, old mainframe jockeys should have no trouble adapting to the modern era.

Since I’m in a retrospective mood, let’s go to the mailbag and follow up on two previous columns, starting with the one that got some of those old mainframe jockeys so upset: my contention that the mainframe is dead. If you’re tuning in for the first time, I claimed that IBM’s new CMOS “mainframes” are really big servers to which IBM has ported the MVS operating system. (See “The mainframe is still dead – but your career doesn’t have to be,” May 12, page 63.)

“IBM could have announced that it had ported MVS to its midrange computers instead. It’s all in how you look at it, of course, and if it makes Big Blue happy to call its new super server a teeny-weeny mainframe, well, so be it,” I also said.

For all the readers who took issue with my assertion, hey, it’s OK if you call it a teeny-weeny mainframe too. In my own satirical way, I was trying to point out that the term “mainframe” has lost all utility and should be retired. I hereby propose a replacement term: “batch server.” Whether the box runs MVS, VMS, or Unix doesn’t matter. If it’s optimized for batch processing – that is, it delivers high throughput, drives very fast printers and mass storage, and ships with software tools for job scheduling, distribution management, and stuff like that – then it’s a batch server.

Speaking of missing the point, the same article included this: “… very little has boded well for OS/2 since IBM took it over from Microsoft.” Many readers mistook this cheap shot at IBM for a cheap shot at OS/2. Complain about my cheap shots all you want, but double-check to make sure it really was your ox I gored and not someone else’s. OK?

Funny thing about the mainframe column. The forum on InfoWorld Electric (http://www.infoworld.com/printlinks/) was pretty lively and ran about 10:1 against my position, often in highly colorful terms. My e-mail ran about 10:1 in favor of my position and offered sympathy regarding the flaming forum. Two samples of reader opinion, both biased.

Bad samples lead to bad conclusions, which brings to mind my recent column bemoaning the lack of error bars and mentioning other flaws in most business presentations of statistics. (See “Pie charts and bar charts may bring comfort, but wisdom is a another matter,” May 5, page 74.) The article made the points that a lot of “information” is simply worthless nonsense paraded as knowledge and that some executives apparently prefer misinformation to ignorance. An important subject, I thought, but not one to arouse passion.

Wrong again. Large numbers of InfoWorld readers sent their compliments, war stories, and personal favorite ways of misleading people with graphs and statistics. This problem bugs people big time, as it should. Spread the word.

On the same column, two readers took the time to provide attribution for the quotation that headed the article (“Statistics are used as a drunk uses lampposts – for support, not illumination”). Joel Miller has seen this quote attributed to Peter Grace of W.R. Grace but can’t vouch for it. Bob Forgrave tells us that he ran across it in advertising legend David Ogilvy’s book, On Advertising.

The world of ideas is a very fractal place.

Fractals, you’ll recall, are geometric constructs in which the same forms recur at different levels of magnification. At close range boulders look like mountains, rocks look like boulders, and grains of sand look like rocks. You have a hard time recognizing which scale you’re looking at.

Ideas are like that too. The same notions and forms recur in wildly different situations, scales, and contexts.

Years ago I read an article contrasting polling and interrupt-driven protocols. I remember little about it other than that the two, although different from an engineering perspective, led to the same user experience when implemented.

Here’s an idea you can take to the bank: Two radically different ways of doing things can sometimes lead to indistinguishable results. It’s enough to make you stop worrying whether Ethernet or Token Ring is better.

What’s that? You’ve already stopped worrying? That’s great, because you can pay closer attention to another fractal recurrence of the polling/interrupt question: the hype over “push” technology.

Pull/push is just polling/interrupt all over again. (I could be wrong, but I doubt it, as Mike Royko used to say.) Push is an interrupt-driven protocol – it’s intrusive. Pull, in the form of offline browsers, is polling – your system initiates the request. Either way you get new information, sorted into channels (another the-name-is-new-and-not-much-else concept), without your having to manually intervene. The only difference I can see is that offline browsers adhere to existing Internet standards instead of introducing proprietary technology.

Push technology should have some network engineering advantages, but even here the situation is pretty blurry. You can implement pull technology so it has no more impact on bandwidth than push, by designing your Intranet so employees stay inside your firewall. The logic behind this is to treat cyberspace the same way we deal with real space.

When William Gibson introduced the term “cyberspace” in his groundbreaking novel Neuromancer, he gave us a valuable way to look at what we do (sadly, the cyberspace metaphor has since been beaten into a cliche). When employees interact with their computers, they are working in the corner of cyberspace we happen to manage.

Let’s compare how we approach company real space and cyberspace. In real space, we pay attention to color schemes, cubicle height, ergonomics, file storage, and some of the aesthetics. We expect employees to personalize their space, recognizing that they spend a lot of their lives inside. Dilbert, and sometimes even this column, get put on the cubicle walls.

In cyberspace we begrudge employees the right to select their own wallpaper, screen resolution, screen savers, and reading matter, calling it “futzing.” It’s supposed to be a colossal corporate expense, and we gripe around the coffee pot about users wasting corporate bandwidth surfing the Web.

Here’s a new mission statement for you: Your job is to turn your company’s little corner of cyberspace into a rich, fulfilling, pleasant, productive place to work. Set up your Intranet so employees don’t want to go to a PointCast server. Give them the news, weather, stock prices, and commuting times. Heck, try designing mission-critical systems so they’re fun to use.

Before you fly off the handle, put yourself on the receiving end of the deal. Who do you want running your company cafeteria, a chef or a dietitian? You have to eat there; employees have to work in your part of cyberspace.

Yes, I know we’re talking about a “waste” of company resources. So is your company newsletter. And employees could survive by eating duckweed salad and tofu burgers (yuck!) in the cafeteria, too. The same idea applies in more than one context: If making your cafeteria a pleasant environment isn’t a waste, then making your corner of cyberspace pleasant isn’t a waste, either.

We seem to have forgotten one of the basics: Making the time employees spend at work pleasant and enjoyable can reap large benefits, whether or not accounting can tally them up in the general ledger.

Should employees really be spending their time reading Web pages that don’t directly relate to their jobs? I don’t know, but I do know that lots of executives spend company time reading The Wall Street Journal, and I’d bet that time has more impact on their career advancement and personal investment portfolios than it does advancing the company strategy.