The angel process is a long-running started task that allows Liberty servers to use z/OS® authorized services. It is required if a Liberty JVM server in CICS® needs to perform authentication and authorization against the RACF® registry.
On z/OS, access to the SAF registry is considered an authorized service. When the CICS security domain makes calls to SAF, it can use its SVC routine, DFHCSVC, which is loaded from the authorized LPA to make authorized calls to SAF. This option is not available to Liberty JVM servers because the CICS SVC is a private interface. Instead, it uses a program call (PC) instruction to another address space, which is itself authorized. The angel process is configured to run authorized, and Liberty servers can connect to it to call authorized services (see Figure 1). When a Liberty server is run in a CICS region, the angel process is the only way for the Liberty server to authenticate users with the SAF registry. The access to its services is controlled by the SAFCRED resource profiles.
Important: Liberty normally offers the ability to fail over to
unauthorized z/OS services to authenticate requests when the
angel process is disabled. If you use a Liberty server in CICS, this function is not supported because CICS does
not support the use of program-controlled libraries.
Figure 1. How Liberty servers call the angel process
Angel process connectivity
A Liberty server can connect to only one angel process at server startup. However, multiple
Liberty servers can share the angel process, independent of the level of code that the servers are
running. By default, the angel process is unnamed, and all Liberty servers will connect to the default unnamed angel process. However, you can use named angels to achieve more flexible
configuration, including sharing an angel process across a selection of Liberty servers.
An angel process can only service Liberty servers that run on the same LPAR. Each LPAR can have
multiple named angel processes but only one default angel process.
Named angel process
Liberty Fix pack 16.0.0.4 introduced the notion of a named angel that allows multiple uniquely named angel processes to run on a single z/OS system, in addition to the default unnamed angel process. A named angel has the same function as the default angel process but it can be used for a selected group of Liberty servers. This isolates different product stacks or Liberty installations from one another so that they can run different service levels or be managed independently.
Best practice: It is recommended to use a single named angel process
for all the Liberty servers that run inside the same CICS
region. This named angel process can also be shared by other Liberty servers within the z/OS LPAR, unless further isolation is required. This condition
occurs regardless of the level of code that the Liberty servers are running or whether they are
running in a CICS Liberty JVM server.
For more information about named angel processes, see Named angel.
Angel process version and interoperability
Liberty servers that are running on a z/OS image can share a single angel process, regardless of the level of Liberty code that the servers are using.
Best practice: It is best practice to upgrade the level of the angel
process before you upgrade the servers that use it. Upgrading in that order ensures continued
support for older Liberty servers while continued access is provided to the latest authorized
services and functions.
Important: You can choose to run a different version of the angel process that is
bundled with another product rather than the one bundled with CICS Liberty. However, no matter which product the angel process is bundled with, it must be
equal to or later than the version of CICS Liberty.
Therefore, if the angel process that is bundled with the other product is earlier than that bundled
with CICS Liberty, you must use the angel process bundled
with CICS Liberty.
You can identify the Liberty version of the angel process and the Liberty server that's running
in CICS as shown in Managing a Liberty angel process.
