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.
---------------
First of all, credit where it is due, I stole this idea entirely from Mitch Johnson.
Alright, so you’ve had lots of meetings and all sorts of politics got tangled with various technical issues and now you’ve got a directory structure to contain your various server configurations. One Line of Business has its server configurations over here, another has them over there, and so on. Perhaps there are some pre-prod test server configurations, and maybe some for Liberty-in-CICS thrown in. And possibly some z/OS Connect servers or other products that use Liberty. And so, despite all the meetings, if you step back a bit it would appear to be a big mess. Oh sure, up close each group is managing its servers in some sort of coherent manner, but looking at the whole environment you’d be hard pressed to think of it as one thing.
And then there’s a problem. Operations declares that the problem is caused by a server with some obscure name. How do you find the config and/or logs for that server? Well, first you need to figure out who owns it and where they keep their stuff. Or do you?
Here’s the idea. Create a single directory, maybe something like /var/LibertyConfig (or whatever you like, just a thought). In that directory you create a symlink to wherever the configuration for that server lives. The link name is, of course, the server name. If you’ve got separate output directories from configuration directories (probably, since you don’t want the server to have write access to its own configuration) then maybe another /var/LibertyOutput contains similar server-named symlinks to each server’s output directory.
Given the name of the server, you can then easily find the config and logs for any server. But, of course, you have to get all the owners of the various servers to actually go create the symlink(s) when they create a new server. I think maybe having this handy directory to find all their servers (and one group might ‘own’ servers under several different config dirs) might motivate them to do it. It also helps enforce system (or sysplex) wide naming conventions so you don’t end up with two servers with the same name.
If you end up with piles of common included configuration files (like all our datasource definitions are included from ‘here’) then you might want to have a link to ‘here’ from the LibertyConfig common directory.
Just an idea…. Thanks Mitch!