Deploying Lozen in a Sysplex

Designed with flexibility in mind, Lozen™ can be deployed in a variety of ways to suit your needs — including in a sysplex to provide load balancing and fault tolerance.

There are several possible approaches to this, depending on the degree of fault tolerance you are looking for.

  • Typically, the most fault-tolerant approach would be to operate several Lozen instances (usually one per LPAR) joined into a single system image with IBM’s z/OS Virtual IP Addressing (VIPA) network technology.

To clients outside the mainframe, this collection of Lozen instances appears as a single resource, and they just connect to a “virtual” hostname that is backed by multiple Lozen instances.  z/OS can either treat Lozen instances as “primary” and “failover,” or it can load balance across available instances on a session level.

In this configuration, if the client is connected to a Lozen instance that fails, the client’s session is transparently redirected to an alternate instance without disruption.  It is important to note that for this to work properly, the sysplex needs identical I/O configuration, security policies, etc. across every LPAR.  You cannot have some files accessible from one system but not from another.

  • In a more manual approach, you can also run as many instances of Lozen as desired, even within a single LPAR. This might be important when it is desirable to have different Lozen instances per application or in cases where I/O configuration varies from LPAR to LPAR — when separating test from production workloads, for example.  In this case, the application would simply connect to a Lozen instance depending on its needs (for example, production versus testing).
  • You can also combine these two approaches. For instance, you might operate a production Lozen deployment that is a VIPA resource bound to multiple instances of Lozen, running one per LPAR maybe.

In parallel, you can also have a separate Lozen instance, reserved for perhaps application testing that exists without any type of redundancy or failover. Applications connect to one or the other simply by specifying a different logical hostname (or host and port).

In all these configurations, the fault tolerance and load balancing are done transparently to the application from within the Lozen z/OS server. The only impact to that application is to ensure the name of the Lozen system it connects to is correct.

On a final note, there might be cases where a Windows or Linux client may lose all network connectivity to the sysplex.  For instance, if a cloud workload loses connectivity due to a network outage at the cloud provider’s site, it may not be possible to communicate with Lozen on z/OS at all, no matter how it is configured.  This should be considered when deploying Lozen so that appropriate fault-tolerant networks and infrastructure can be included outside the mainframe, too.


Lozen is VirtualZ Computing’s revolutionary solution that unlocks the power of real-time, read-write data access — from any platform, anytime, anywhere.

It can be deployed in a variety of ways to suit your needs, including in a sysplex to provide load balancing and fault tolerance.

Learn More

To learn more about how to unlock the power of real-time, read-write mainframe data access with Lozen:

Latest Blog Posts

PropelZ Use Cases

PropelZ Use Cases

PropelZ — a fast, no-code utility from VirtualZ — is designed for businesses who want to use a quick snapshot of their mainframe data in their hybrid cloud environments. With PropelZ, you can push a scheduled, near real-time copy of mainframe data to a wide variety of...