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.
---------------
If you start a Liberty server as a started task, you’ll probably use (at least as a template) the sample JCL PROC provided with the product. It is called BBGZSRV. Maybe I should explain why. Every IBM product (and sometimes components within a product) gets a 3-character product prefix. This is used as a prefix for message IDs, part names, and things like that. The WAS z/OS product (way back when) was assigned the prefix BBO. That was something of an inside joke. WebSphere was originally called Component Broker, but internally the project name was ‘BOSS’. I’ve forgotten what that stood for..something Object Server? Anyway, the initial implementation of BOSS was on distributed (mostly Windows/Linux I think) and when we started writing the z/OS version it was called BIG BOSS. And thus BigBOss or BBO.
Anyway, when WAS z/OS added 64 bit support we needed new part names just like the old part names, but for 64 bit. Since all the IBM Z hardware instructions for 64 bit were ‘grande’ instructions, using the ‘G’ for the 64 bit flavors made sense. Thus the BBOBOA load module in 31 bit was the BBGBOA load module in 64 bit. And since Liberty only runs in 64 bit, it made sense to use the BBG prefix. And then the rest is the z/OS Server (ZSRV) vs the z/OS Angel (whose proc is BBGZANGL).
Ok, so what is in there? Well, there are two paths you need to set as variables up at the top. These are INSTDIR and USERDIR. The INSTDIR variable points to the zFS directory where the installed product code lives. We’ll need this to find the server launcher code. The USERDIR variable is used to set the WLPUDIR DD path. That DD is used to find the config and as a basis for things we might need to write (traces, etc).
The server itself is launched using BPXBATSL. That’s a flavor of BPXBATCH that does a spawn-local (hence SL) which means the thing run by BPXBATCH runs in the same address space as BPXBATCH and not in a BPXAS address space. That’s important. You want the server to actually be IN the started task you started and not somewhere else.
The PROC also specifies REGION=0M and TIME=NOLIMIT. The TIME value should be pretty obvious. This is a server so you don’t want it to get blown away because it has been up for too long. Ideally it will stay up until you want it to go away (to put on maintenance etc). The REGION value might be a bit controversial, and seem odd since the server is running in 64 bit and most of its stuff will be above the line anyway. We’ve found setting this just helps avoid weird problems. By the way, you should look for messages CWWKB0125I and CWWKB0126I which are issued during server startup. They report the REGION and MEMLIMIT value you actually got (installation exits might ignore the REGION=0M and set something else). If you’re having problems getting the memory you think you should be able to get, check these messages to see what limits you really have.
The last thing I’ll mention is that BPXBATSL is used to run the program at &INSTDIR/lib/native/zos/s390x/bbgzsrv. That program is the bit of C code that will get the JVM started and run the Java code that will become the Liberty server.