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.
---------------
It actually doesn’t have to be different, although it depends a bit on what you’re talking about. If you’re talking about product packaging and pricing and that sort of thing, then yes it is different because IBM products for z/OS are just handled differently than products for other platforms. I’m certainly not going to get into that here.
But from a technical perspective, it is possible to run a Liberty server on z/OS and have it behave just like it does anywhere else. You can use the server script to start and stop it from the shell. If there is no Angel (we’ll get to Angels later) or it doesn’t have permission to use one, then none of the z/OS extensions that require authorization will be used. And if your server.xml doesn’t include any z/OS specific features, then you won’t get any of those either.
For the most part, a server configured like you would configure it to run on a non-z/OS platform will behave exactly the same on z/OS as it would anywhere else. Offhand the one difference you might notice is that the server will register with z/OS so it shows up in SCRT reports (we’ll talk about how that works later on also). But that isn’t really a server behavior thing, it is more just part of that whole IBM z/OS software pricing thing I’m avoiding.
But all that said, you can choose to make it behave in z/OS specific ways. There are a lot of very cool things that are part of the z/OS environment that you might want to take advantage of. And I should point out that these are mostly things that are just operational and don’t impact your application code at all. If you are classifying work with WLM or using a SAF security registry or producing SMF records, the application doesn’t care.
I’ll get to all these points of integration and exploitation later on, but at a high level why would you want to do any of this? Well, you are running an application server on z/OS and so it should behave as you’d expect things to behave on z/OS. For example, servers processing requests on z/OS should produce SMF records. z/OS customers expect to be able to look at SMF data to understand their workload. Merging SMF data from various aspects of the system to understand the big picture requires everything to produce SMF records.
This integration with the operating system is one of the things that distinguishes Liberty on z/OS from other open-source application servers that can be run on z/OS. I won’t name names here, but there are quite a few things out there you could choose to run on z/OS (written in Java or maybe written in C and could be compiled for z/OS) but they will behave like a server running on a distributed platform. Liberty z/OS can be configured to behave like you’d expect a z/OS based server to behave.
Yet deep in its heart, Liberty z/OS is the same as Liberty anywhere else and so your applications don’t change just because you’re running on z/OS.
I’ll close by pointing out that I’ve avoided entirely talking about whether z/OS itself is a good or bad platform for your application. You can code your application to run in Liberty anywhere, and if you run it on z/OS it will integrate into the platform appropriately without any changes to the application itself (well, probably…I’m sure there are exceptions).