History and culture make it surprisingly hard to find good information about mainframe development on the web.

I manage a team of software developers, and it’s an eclectic bunch. Among the folks currently under my purview are web developers, client-server developers, and a fair number of people doing mainframe work in the old-school batch processing style, using COBOL, REXX, and the whole nine yards.

I’m often struck by the differences between the culture of the mainframers (I’ll resist abbreviating them as the MFers) and the culture of, say, the web developers. Both groups get the job done, but they prosecute their work in very different ways.

I can’t remember the last time I wrote some code by following a book. The average web developer knows enough Google-fu to look up almost any low-level fact or code snippet they need online. The average mainframer, however, goes to the bookshelf first, or to another programmer, at least in my shop. Using the web to search for solutions doesn’t even seem to be part of their regular toolkit. Rather, web searches are an exotic choice, something they try when other options have been exhausted. One of my mainframe guys used the web to get some snippet of COBOL a couple of years back, and the experience became a story for him – something that he recounts occasionally with a who’d-have-thunk tone of surprise in his voice.

I wondered why this might be, until I had occasion to do some web research for a mainframe issue, and realized that the amount of mainframe knowledge resident on the web is amazingly thin. There is certainly quality info to be had from IBM and sites like http://theamericanprogrammer.com/, and you can seek out expert advice in the discussion forums hosted by http://ibmmainframes.com/, among others. However, in total, there are really only a handful of quality locations for mainframe know-how that go beyond the “Fred throws up a page full of links” variety.

The other day, I had a question concerning batch ACIDs. An ACID (short for Accessor Id) is mainframe parlance for an account. When you log on to a mainframe, you supply your password and ACID, which is basically a username. Once authenticated, you get access to TSO/ISPF (assuming an IBM system), which is your vehicle for interacting with the OS in a synchronous fashion. From there, you navigate through screens (panels) and issue various commands. To tell the mainframe to do anything substantial, such as run a program that processes data files, you will execute a batch job. After you submit (initiate) the job, it goes off and runs on its own. You have tools to check whether it is running, but you don’t actually hear from it until it finishes, at which point you will receive a notification from the OS (if you asked for one) that it has either completed successfully or abended (errored out). A so-called “batch ACID” is an account under which only batch processes run – you can think of it as being like an account that gets used by an application instead of a user. In a given environment, specific user ACIDs will have the permissions needed to kick off jobs that execute under the authority of a given batch ACID.

So, back to the question I had – one of the sys admin types (system programmers, in mainframe parlance) wrote to say that he was changing the passwords for a list of batch ACIDs, and wanted to know if this would screw up anything my team had running in production. I, for one, didn’t know that batch ACIDs could even have passwords (not all batch ACIDs do), and so my response was to make a noise that approximated how Scooby Doo would respond if somebody asked him to explain the Central Limit Theorem. Apparently, since my team wasn’t hard-coding passwords for batch ACIDs in our JCL (Job Control Language – the commands that tell the OS how to run batch jobs), our production stuff wouldn’t get hosed, but I was unsettled by the recognition that I obviously knew very little about the z/OS security model and how batch ACIDs actually work.

So, I decided to do a little research on batch ACIDs. Being a simple man of simple mind, I am driven to simple tools, and so I pounded batch ACID into Google. Huh? As of this writing, none of the first-page results have anything to do with the subject in which I’m interested. Instead, I’m seeing links to DJ software and plant amino acids and industrial waste and a host of other things I don’t really want to see. Go ahead and try it yourself. (If this page shows up in the results, then you have to give me a pass on that.) Well, since that didn’t work, I guess I should try it with quotes. Now at least I get one relevant hit – an article that deals with security for batch ACIDs, but doesn’t really do much to explain what these are.

The thing is, “batch ACID” seems like a pretty specific term to me. I don’t think the mainframe world has much competition in the use of this phrase, unless you count Timothy Leary’s party preparation guides. So, I’m pretty surprised that the searches I attempted weren’t more fruitful.

Earlier, I said a batch ACID is more or less like an account used by an application. I wondered what would happen if I tried to search for application account. Offhand, I’d have guessed that I wouldn’t do so well – this phrase would seemingly cross into many more domains than batch acid (think of all the people who fill out applications for accounts that having nothing to do with information systems), and it doesn’t even corner the market in its niche, since there are comparable variants such as service account in common use.

Yet, lo and behold, if I run a search for application account, I get a few hits that cover exactly what I mean. Further, if I use quotes, I do a little better. Even though batch acid is such a unique phrase and application account is dirt-common, the former yields little search gold while the latter pans out right away.

We could repeat this with other examples. Finding info about mainframe topics, error messages, and the like through a search engine is often a frustrating process. No doubt, the info about batch ACID security that I wanted to find is buried in an IBM Redbook somewhere (these are posted online), and nobody should moan about having to look though a few pages of results to find germane content, but I think that this example is illustrative of my basic point that mainframe info is pretty tough to find on the web, at least relative to many other technologies in wide use today. (Contray to semi-popular belief, mainframes are in fairly wide use.)

There are many ways to explain this – obviously, the heyday of batch mainframe processing and associated technologies preceded the widespread use of the Internet, and so the web missed the “sweet spot” period for classic mainframe technologies. However, many boutique technologies see only a fraction of the market share enjoyed by legacy-style mainframe techniques, and yet these technologies are easy to research on the web. Mainframe stuff isn’t on the web in any amount even vaguely proportional to its actual usage, or so I contend. This is not only a function of history, but of culture as well, and it will remain the case as long as mainframe pros adhere to the default search chain of book / body / broadband when they need info or care to share it with others.

CAVEAT LECTOR: Please don’t rely on my description of a batch ACID for anything important. I’ve related the nature of ACIDs and batch processing as I understand these, but I’m sure a knowledgable party could find many faults in my explanation. I’d like to direct you to a good link where you can learn more, but I’m still looking for that myself . . .