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.
---------------
You’re probably going to want to set some environment variables for your server and it turns out you’ve got a lot of choices about where to set them. If you’ve experimented with Liberty at all, you’re probably familiar with the server.env file. That’s where most people put their environment variables. But it turns out that Java also has a java.env file and you can have a default.env also. Those live where the runtime is installed (WLP_INSTALL_DIR), which might be mounted read-only or have other protections to avoid it being updated. Still, it is good to be aware the server looks there too.
If you launch your z/OS Liberty server using the JCL PROC, you have another option. The PROC uses a flavor of BPXBATCH to start a C program that, in turn, starts the JVM and the server. Because BPXBATCH is involved, you can also make use of the STDENV DD that it will read to set up environment variables. Because this runs before any WebSphere code is involved, it will get the first opportunity to set up variable values.
Another interesting trick with STDENV is that, because it is a DD, you can have it point to multiple files by concatenation (just like STEPLIB or other DD concatenation). This allows you to spread things out in different areas, if that makes sense for you. Although unlike server configuration include files, there is no way to tell JCL that a file is ‘optional’ so if you have a DD pointing to it, it better be there.
You could, if you wanted to, have the STDENV point to not just files in the USS file system (zFS) but also to actual datasets. You could put your environment variable settings in a sequential dataset or in members of a PDS. Would you want to do that? I’m not sure that’s a good idea, but it could be there’s some change-control situation that might find that helpful.
Whether you start the server from the shell using the ‘server’ script or as a started task with the JCL PROC, all these sources will get read and processed to set up your environment variables. But, at least as I’m writing this, there is one difference. Liberty added the ability to expand environment variables within the server.env file. So if, for example, you had an environment variable HTTP_PORT set to 80 and then a later environment variable, call it ‘X’, was set to ${HTTP_PORT} it is possible to get Liberty to resolve HTTP_PORT before setting ‘X’ (a terrible name for an environment variable).
Right now, this variable expansion only works if you start the server from the shell using the ‘server’ script, and you must indicate (by special text in the first line of server.env) that you want it to happen. If you start out experimenting with servers started from the shell and later move to using started tasks, this might be an issue. Or, perhaps by the time you read this, things will have changed.