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’ve started Liberty on another platform, you probably used the ‘server’ script to start and stop it. You can do that on z/OS also. Just get into the USS shell and run the same ‘server’ script you’ll find in the Liberty bin directory, just like you would anywhere else. On z/OS that will result in your server running in a BPXAS address space, just like any other thing you run that way.
Since you’ve got all the z/OS extensions as part of the runtime, it will still be able to do all the z/OS stuff. You’ll still be able to classify work with WLM, get SMF records, etc. From SDSF or console commands (like “D A,L”) it will be tough to find. The only way I’ve worked out to find it is to look in the messages.log file. Near the top you’ll see a line that says “process =” followed by a process id, an ‘@’ sign, and the userid the server is running under. Then the console command “D OMVS, PID=” with that process id will give you the jobname and ASID.
So, this is an ok approach for a developer who wants to be able to start and stop a server, just like is done anywhere else. But for a production server, you’d want it to look and feel more like a typical z/OS production server thing. It should really be a started task.
Well, ok, you could create JCL that would run some flavor of BPXBATCH to run the ‘server’ script and that would kind of work, although I think you’d still end up with the server in a different address space…maybe. There’s a lot I’ve forgotten about managing USS processes. And in any event this is kind of clunky.
Fortunately, WAS Liberty on z/OS comes with a JCL PROC that will run a bit of C code provided with Liberty that will launch the server right there in the JCL-driven address space without any funky script stuff in the middle.
Next week we’ll take a look at the PROC, but for now, what is doing it this way going to get you? Well, first off the server will run right there in that started task address space without any tricky stuff. Whatever SAF definitions you have for started tasks will control the userid the server runs under.
Any WTOs issued by the server will come from the started task with the name you gave it. This will make things a lot easier for any automation you want to write to manage these servers.
Liberty on z/OS also responds to some console Modify commands (more on that later too). Being able to easily find the server address space makes it possible to send a Modify command to the server you want it to go to. Hard to do when you can’t find the right address space. And, of course, you can find the server’s job output in SDSF because you know what the thing is called.