mainframe.dev

 In this post I want to dig deeper into a phenomenon that I spent a few day debugging with friends. It will be a story of a behavior that seems illogical at first glance, broken even, but will seem feasible in the end. Let's begin! Things you will need: The scenario requires one host and one switch minimum*. In our example we will use two Linux hosts, an Arista DCS-7050S switch, and an Arista DCS-7050QX switch. The second switch and host is not strictly needed, but it makes the scenario more realistic and is how we found this issue. The story begins with you and a couple of friends are building an internet exchange (IX) for education and for fun. The simplest IX is just a simple switch - yes even an unmanaged thing you can pick up for $10 would work theoretically. The switch has one purpose: connect different actors together so they can route traffic between each other. See diagram 1. Diagram 1: Your typical IX network. It's just a switch. You have your IX switch and you have y

I have done systems administration for as long as I remember, and while I have set up countless of services and servers - I have quite limited experience working with the full life-cycle of truly enterprise software. Therefor, I thought it would be interesting to understand more on how one would plan for and execute updates on an IBM Z Series mainframe.

I have to make a post mentioning the last couple of months, anything else would just be weird I feel. I hope you all are doing as well as can be in these unpredictable times. I know I have been personally affected by this pandemic in multiple ways yet I feel fortunate - things could have been so much worse.  While I am one of the lucky people who work in a job that lends itself reasonably well to work from home, it took some time to get used to which had me focus more time and effort on things like home improvements and new daily routines to help me adjust to this new way of living. Thankfully I was not alone in this journey and I am thankful to all my friends, family, and of course my partner for being there for me. We all need to take care of each other. The last couple of weeks I have resumed my work on mainframe related projects and I have a series of blog posts that I wish to publish coming up. Some of these topics are going to be deep-waters territory for me, but the community ha

Wow, time flies. In the past months I've been working on a handful of projects related to the mainframe, but nothing that is really finished - so I thought I would summarize some work I've been doing instead.

The latest project I've been working on is a custom card that will allow me to interface any mainframe using the FICON protocol. I have a lot of ideas on how this could help a lot of hobbyists out there, and possibly folks doing development for mainframes as well. For my own purposes, it would allow me to not be reliant on my (still broken) DS6800 array. DE5-Net card running fejkon

The last couple of weeks I've been traveling for work, and I spent a long flight reading some publications I had saved up about mainframe and Fibre Channel. I will talk about some good sources of information later, but for now know that FICON runs over Fibre Channel, and indeed a lot of the reasons behind why Fibre Channel is known to be really reliable is that it more or less came out of IBMs requirements for accessing mainframe disk storage. Enterprise disk storage has this annoying issue that the disk arrays are: Heavy Power-hungry Ridiculously expensive An example: DS6800 is widely known to be an unreliable platform, and I would certainly never run a mainframe on it based on my experiences repairing mine. However it is as small as disk arrays get, but it is still 50 kg empty, and consumes 500W of power! However the DS6800 is kind of a black sheep in reliability. What if we look at something bigger and better? The big brother DS8000 is known to be rock solid fo