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.
---------------
A couple of posts back I said, “the Angel and the servers using it have to be at the same code level”. This raised a few questions, especially because the official documentation doesn’t say that. In the immortal words of Luther Heggs (Don Knotts) in The Ghost and Mr. Chicken, “Let me clarify this.”
There is nothing in the code that actually enforces anything about the code levels of the server and the Angel it connects to. However, we do occasionally ship updates to the Angel code that are required to allow some new function in the server to work. If you’ve got a server with the new thing and connect it to an Angel without it, the new thing won’t work right.
Which means that you can just maintain the servers and Angel independently and hope for the best. If you have a problem caused by a server getting ahead of the Angel, you can catch the Angel up and sort it out. The server will issue a message (CWWKB0127W) to warn you you’re using an Angel that is behind the server and has crossed some change to the Angel code. Again, having a situation where the Angel is missing some code the server might need might not cause a problem, depending on what we did and what the server is using. But it feels unnecessarily risky to me.
You can also choose to carefully manage things. I call this the “at or above” strategy. Basically you keep track of what levels all the servers are at that use a particular Angel and you make sure that Angel is always at-or-above the highest level of servers using it. This will always avoid the level-mismatch issues from just above. But it seems very complicated and messy to me.
Lastly, you can do as I’d said in the earlier post and just keep the Angel and all its servers at the same code level. If you need to run servers at multiple different levels, group them under appropriate Angels.
If you need to shift a server from one Angel to another, you can do that by changing the Angel name it binds to in bootstrap.properties and updating the SAF permissions required for it to use the new Angel. This is nothing like trying to move a server from one cell to another in TWAS. Although it might cause your automation some issues.
The current documentation as I write this says conflicting things about all this and I’ve got an issue open to try to clear that up.
You do have some options, but I think the simplest thing, that requires the least bookkeeping, and has the least chance of having problems, is to keep the Angel and the servers connecting to it at the same level.
I guess what I said a couple of posts back is more of a guideline than a rule (Barbossa – Pirates of the Caribbean).