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.
---------------
By now you should be beginning to have some idea of the things you’ll need to do to create a new server (or perhaps a new group of servers). Actually creating the server, of course, involves running the ‘server create’ shell script with certain environment variables set pointing to things like where Java is and where the configuration should go. You’ll need to supply the server name too, of course.
You might want to create some symbolic links as we’ve discussed previously. If you’re creating a whole new group of servers you’ve probably got some file systems to create and mount points to define.
Depending on how you’ve decided to manage things you might need an output directory created. And there are assorted permission bit changes and file ownership changes you might want to make.
As you start working out how you’re going to go about creating a new server to fit into the rules for your environment, you should try to write down all the required steps. That’s not just because it is nice to have a written-down process to follow.
It is probably worth your time to create a script, or some JCL, or some combination that can actually execute all these steps for you. Obviously you’ll have to provide some parameters like the server name and such. Besides making it easier to define new servers, this also makes it harder to accidentally skip a step in your defined process and create hard-to-figure-out problems down the road when something isn’t quite right.
You could also, if you were so inclined, create a z/OSMF workflow that can run your JCL or script or combination of things. There’s a REST interface to execute workflows in z/OSMF that might then allow you to tie this whole thing into some larger administrative process.
Of course it could be that despite having such a neatly defined process, you’re just a bit reluctant to let people with access to a REST interface (which you can control, of course, but still) go off creating new servers on your z/OS system.
I get it. But remember all this is really doing is creating a bunch of pieces in the file system. There’s still a bunch of RACF (or equivalent) stuff to do to grant access to the Angel or other things the server needs. You could, of course, include issuing those RACF (or equivalent) commands in your script/JCL. If your security administrators will let you.
And it won’t start as a started task without a change to automation. Perhaps there are WLM definitions that need to be adjusted (depending on how the started task is named).
There can be a lot to do to get a real production server defined. We’ve talked earlier about being open to letting developers create their own servers for dev/test purposes. I think production servers are a bit different and require some thought in their creation. But that doesn’t mean you shouldn’t look for opportunities to make your life easier as a sysprog and automate things where you can.