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.
---------------
If you start messing about with Liberty on z/OS you’ll quickly run into documentation that talks about the Angel process. In this post we’ll take a look at what the Angel is, what it does for you, and, the obvious question, why it is called that. We’ll save a discussion about whether you need one or not for a later post.
The Angel runs on z/OS as a started task. It runs as an authorized program, meaning that it is in key 2 and generally in supervisor state. That allows it to do z/OS authorized things. Well that’s nice, but why do we need it?
Well, a Liberty server runs on z/OS as an unauthorized program. No matter how you start it, the server is running in key 8, problem state. That’s great because you have application programs in there doing who-knows-what and those things should run unauthorized.
But, in order to allow that server to exploit and integrate with z/OS system services, sometimes it needs to do authorized things. Or rather, it might need to do authorized things. It depends how you configure the server and what you want it to do.
Thus, if you configure your server to use features that require running code authorized the server needs some way to get authorized to do that. And that’s where the Angel comes in.
Again, we’ll save the discussion of how it does this for a later post, but for now we’ll just say that the Angel hangs around being an authorized program that the servers can exploit to run authorized code if they need to in order to do authorized things you’ve configured them to do. It owns key 2 control blocks in common storage and establishes PC targets that, when called, will result in code running in key 2 on behalf of the caller. If the Angel isn’t available or the server isn’t allowed to use it (also a topic we’ll get to later) then the server can’t do the things that require it to run authorized.
So why is it called an Angel? Well, in WebSphere traditional we had a sort-of-similar process called a Daemon. This was named in the long Unix tradition of such supporting processes being called daemons. With Liberty we wanted to distinguish this address space from the WebSphere traditional Daemon. Also, there were some ‘issues’ that the Daemon had that we attempted to resolve in the design of the Angel (starting from scratch and all) which made this new thing not-a-Daemon. Well, the obvious thing that isn’t a Daemon is an Angel.
And so, internally, it got called an Angel process (very frequently misspelled as ‘angle’). We assumed that somewhere along the way somebody would tell us that we couldn’t actually call it that and we’d be forced to name it something awkward (I liked authorized-server-support, but it doesn’t acronym well). But time passed, the name got burned into all the code and documentation and messages and it became harder and harder to change. And nobody ever said anything about it.
And so that’s why it is called the Angel. Basically because nobody told us we couldn’t call it that.