This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
This week I thought I’d tell the story of how named Angels came to be a thing. The original design allowed for a single Angel per z/OS image. Any server that needed an Angel would just connect to it and the Angel would help it do authorized stuff. The Angel itself didn’t really do anything, so it seemed like the Angel would just sit there, with no real code level dependencies between the server and the Angel. There was hardly any code in the Angel to be compatible with the server. So you wouldn’t need to even restart the Angel to put on maintenance when you updated the server code that was using it.
At least, that was the idea. In practice it turned out to be harder than that. It turned out that sometimes code updates to the server DID require new code in the Angel. And that meant you might update the server code and need to restart the Angel.
Oh dear. Well, now it could be the case that you’ve got some servers using the Angel that don’t get code updates and some that do. And when you have to restart the Angel to put on the update to go with the updates to some servers, you’d have to shut down all the servers using the Angel (more on that in a later post). Well, that’s just very disruptive.
And, it turned out, that not all the servers on a given system might be managed by the same people. You might have a Liberty server used for z/OSMF, some more for your own web applications, and yet more running inside CICS. All those might be managed by different groups. And if you need to restart the one Angel they are all sharing…well..that’s going to be a problem
So we had to support more than one Angel. We’d then need a way for the server to know which one it was supposed to use. Well, the easy thing was to just give it a name. By default the Angel has no name (because it didn’t have one when there could only be one Angel). If the server doesn’t know what Angel to connect to, it looks for the nameless Angel.
But you can start an Angel and give it a name. And you can configure (in bootstrap.properties) what Angel name the server should look for when it starts. As we noted last week, the Angel name is part of the SAF entity name used to check for access to the Angel. That allows you to enforce that servers can only connect to the Angel you want them to connect to.
So what should you name your Angel? Well, how many characters do you get? It turns out the limit is dictated by how long that entity name in the SERVERS SAF class can be. After the other parts of the name are subtracted out (which are fixed in length) you’re left with 54 characters you can use to name your Angel. Yet still I often see it as a cryptic, boring, 8-character name. Come on folks, be creative. There are lots of angel names. Wouldn’t you like to see a message about your server connecting to MICHAEL-ARCHANGEL? (I think a dash is ok, I didn’t check). Or GIDEON? Or perhaps, if you have an Angel that you basically never start, you might think of it as a fallen angel…. Should make for an interesting conversation when somebody important notices anyway.