Czech and Bavarian deer behave like some IT practitioners: their habits are hard to break. Animal researchers have discovered that deer living on either side of the now long ago disappeared Berlin Wall still remain on their respective sides of the border. Adult deer have a life expectancy of about 15 years, and the Berlin Wall came down 25 years ago. None of the deer alive today have even seen a functioning Berlin Wall, yet they don’t cross that invisible line.

There are many invisible lines that some IT operators still do not cross. One example is restarting — “reIPLing” in mainframe vernacular — z/OS. There are many IT organizations with mainframes that reIPL z/OS on a regularly scheduled basis. Perhaps nightly, perhaps weekly, perhaps monthly. Why? Basically because their predecessors did — or maybe they did, since they have longer life expectancies than deer — starting some decades ago. For example, there might have been a memory leak IBM or another vendor fixed in 1974, but the operations team added a regular reIPL in 1973 in order to work around that particular problem. That was a great idea 40 years ago, but then nobody canceled that particular operational workaround.

The persistence of such obsolete operational practices could be a big problem. If the deer don’t cross that particular invisible line, their business users might not appreciate being knocked offline “just because.” Then somebody might decide to start shooting the deer, metaphorically speaking.

Please don’t act like a Czech or Bavarian deer. Try crossing a few invisible lines once in a while. Whether you’re a Millennial Mainframer or not, act like one. In this particular example, how about skipping the next IPL? You’ll then verify that your Cold War against memory leaks ended decades ago. Or implement Sysplex — inside a single mainframe works fine — with two production instances of z/OS and associated middleware supporting your most critical applications so that, if you insist on continuing to reIPL one instance, the other will keep providing business service to your users. There are some rather easy solutions to help you cross at least that particular invisible line affordably and with confidence.

It’s more than a bit frustrating when a computing technology (the mainframe) is more than capable of satisfying demanding business requirements, but a few people operating them or implementing them don’t support mainframe capabilities.

Please be a dear, not a deer.

They’ve reportedly been down hard since April 12. Reportedly five servers failed, and it’s taking weeks to locate and install parts. Wow.

The EOIR is supposed to adjudicate immigration cases in the United States. If your immigration case cannot be heard you’ll either not be cleared to stay in the United States until some time in the future, or your removal from the United States will be delayed. You’ll continue to be stuck in limbo, in other words. That might be good news for some, but overall it’s a disaster. An unrecovered one thus far.

It sure would be nice if the EOIR bought a modern mainframe. Or simply used a small portion of a modern mainframe at any of the U.S. government’s many agencies with mainframes, including the U.S. Department of Justice itself.  The U.S. government already has a mainframe-based cloud. My advice would be to use that mainframe cloud more and more often to help the EOIR and other agencies stay up-and-running.