Category Archives: Learning

Upgrading a Desupported Version of Ubuntu

When upgrading a desupported version of Ubuntu, make sure to include the prescribed old-releases.ubuntu.com URLs in your sources.list, but also comment out the corresponding URLs from the regular releases site.

Shamefully, I let the OS on the VPS (virtual private server) which runs this blog fall out of support. I was running Ubuntu 9.10 (Karmic Koala – shudder), which apparently went of of support in – yikes! – April of 2011.

Okay, so no big deal, right? I’ll just upgrade to a supported version. However, once your flavor gets too far out of support, it turns out that the baked-in upgrade tools don’t work so well any more, and you have to do some extra gymnastics. Specifically, some of the packages you need in order to upgrade get kicked off of http://releases.ubuntu.com and moved to http://old-releases.ubuntu.com, so you have to edit /etc/apt/sources.list to include some references to the Ubuntu retirement home. The basic process is described on the Ubuntu “End of Life” upgrade page, and Google-fu will reveal a number of helpful tutorials on the subject.

I did the things prescribed in the above-linked EOL upgrade instructions, but when I went to install the new version of update-manager-core in preparation for the upgrade, I was met with a raft of 404 errors. I re-read the instructions, Googled like crazy, ran apt-get using every switch imaginable, and even sprinkled some goat’s blood on my keyboard (#offensive!), but I still couldn’t get it to work. I got pretty frustrated, especially because I don’t have much depth in this area, and am ill-equipped to problem solve if the cookbook approach fails.

After some swearing and deliberation, I finally did something that may seem common-sensical but which was not at all obvious to me. In fact, when I did it, I thought I was throwing up a Hail Mary. I had already added the required sources in /etc/apt/sources.list, as below:

## EOL upgrade sources.list
# Required
deb http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse

# Optional
#deb http://old-releases.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse

So, on what I thought was a long shot, I commented out the corresponding entries for releases.ubuntu.com, and gave it a whirl again. To my surprise, that was the special sauce I needed, and the update manager refresh proceeded without a hitch. (If only that were true for the rest of my upgrade, but that’s a tale for another time.)

So, maybe that last part was laughably obvious to some, but it certainly wasn’t obvious to me (how should I know what kind of search chain is being used?), and I hadn’t seen it in any of the “cut and paste” cookbooks I had consulted. Hopefully, some other Linux-inept schmuck will read this and be spared some of my torments.

Relearning My Lesson

Already knowing something is a terrible reason for not learning it again.

Last year, I decided that I didn’t like a certain person, based on fleeting observations, cursory interactions, the testimony of others, and a raft of tenuous inferences.

Yesterday, circumstance put me in a position to actually talk with him for the first time. It turns out he’s a pretty good guy – intelligent, interesting, engaged, funny, and self-deprecating without telegraphing a sense of false humility. I was flat wrong about him.

I was surpised by my discovery, but of course, I shouldn’t have been. It’s happened to me before – making judgments based on shaky evidence, and coming to a false conclusion about somebody, whom I then write off, until I am proven dramatically wrong. Based on past situations of a similar nature, I should have known better about being so judgmental – actually, I did know better – but I repeated the mistake anyway.

Knowing something (e.g., don’t judge a book by its cover) and even really believing in it (having some emotional affinity for the knowledge) is quite different from mastering it. Mastering it, to the point where you are consistently faithful to it, takes a good bit of practice. The mere fact that you assent to a given proposition doesn’t make it second nature to you. It only becomes second nature when you purposefully keep it near the top of your consciousness, where you can recollect it readily and then live accordingly.

That’s why trite sayings, truisms, and other fundamentals that we come to take for granted are really very important to hear. For most ideas, repetition and reinforcement are as important as the original learning. While I sometimes chafe at the expression of basic truths / principles, and quietly dimiss those who offer them as unsophisticated, it turns out that I often need a refresher on such truths.  When I was 17, I was fairly good at calculus, but virtually all of that discipline is lost to me today, chiefly for lack of practice with it. I’d hate for that to happen with many other pieces of knowledge that are in principle already known to me.

Sooner or later, I’ll let my recent lesson about snap judgments drift out of memory, and not far after I’ll be doomed to repeat it. Hopefully, after I re-learn it enough times, I’ll get to the point where I finally know it – by heart, so to speak.

Mainframes Aren’t on the Internet

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 . . .