Fig. 2.1: Architecture and Implementation
FLEX-ES implements IBM's z/Architecture® computer architecture in software. This is the single most important concept. Everything else follows from it.
FLEX-ES provides several different architectural modes. Some of these modes include older functionality no longer present in z/Architecture. The architectural modes are: 64-bit z/Architecture, 31-bit z/Architecture (including ESA/390,TM ESA/370,TM and 370-XA compatibility), System/370, and, for those very few situations requiring it, ECPS:VSE.
System/360 and its successors through z/Architecture have all been defined in terms of an abstract computer "architecture" which is independent of any particular implementation technology. This approach has allowed manufacturers to build computers which implement the abstract machine architecture while using whatever technologies are most appropriate. As a result, this family of architectures has been able to span many generations of implementation technologies, from early integrated circuits in the 1960s to CMOS and other technologies in the 21st century.
FLEX-ES is therefore a natural step in the evolution of mainframe implementations, because it implements this mainframe architecture in the technology now best suited to its scale: software.
To illustrate this, consider a mainframe installation in very schematic terms as a triangle or pyramid. In the accompanying illustration, the left pyramid represents a traditional implementation. At the base of the pyramid is the hardware (including any firmware or microcode). This hardware presents to the world a machine of a particular architecture. To everything above this "architecture/implementation" line, the details of the hardware are irrelevant.
Fig. 2.1: Architecture and Implementation
Above this line is the mainframe operating system, and at the top of the pyramid, in this greatly simplified view, are mainframe applications.
In practice, the application level is the level of primary interest to users, while the mainframe OS level is of primary interest to systems programmers and administrators.
In the FLEX-ES pyramid on the right, these top levels of mainframe operating system and mainframe applications are exactly the same as in the pyramid on the left. From the point of view of the mainframe operating system and mainframe applications, FLEX-ES is indistinguishable from traditional hardware-based mainframes because it is a mainframe, just as they are.
At the implementation level, FLEX-ES replaces traditional hardware with a layer of software (FLEX-ES itself, in its various components) running on some underlying platform (server, host).
The actual configuration of a FLEX-ES system is slightly more complex than this very simple view, as FLEX-ES can, due to the flexibility of software implementation, provide capabilities not possible in traditional mainframes. However, from the point of view of mainframe operating systems and applications, this simple model remains valid: FLEX-ES is a mainframe computer.
It is also correct to speak of FLEX-ES as an "emulation" of the mainframe architecture, or of the product as an "emulator." This term can become confusing, however, because it may connote some suggestion that FLEX-ES is something other than a mainframe.
It is not correct to refer to FLEX-ES as a "simulation."
As used here, the term "emulation" means something which provides the same functionality as some other item by different means. Thus, a terminal emulation program provides the same functionality as a traditional terminal, but it does so in a window on a server or workstation rather than as a separate piece of hardware. In this sense, FLEX-ES does emulate the mainframe architecture insofar as it implements this architecture using modern software technologies rather than traditional hardware technologies.
As used here, "emulation" should be distinguished clearly from "simulation." The term "simulation" means something which provides a model of some other item without necessarily providing the actual functionality of that item. Thus, a program which simulates traffic flow on a freeway is a simulator of that freeway but it does not provide actual transportation. A flight simulator behaves like an aircraft, but doesn't fly. In general, while an emulator is something that you can ask to do the actual work of something else, a simulator is something that you can ask questions of in order more fully to understand something else.
This section presents examples which illustrate how FLEX-ES differs from other mainframes, with particular attention to showing how FLEX-ES differs from IBM's VM operating system and from the Logical Partition (LPAR) capabilities of IBM's PR/SM Facility. These examples are intented to illustrate relatively simple cases, and are not exhaustive.
Note also that while these examples illustrate possible configurations of traditional systems, they are not intended to illustrate common situations. Few VM installations, for example, would in practice be configured in the ways shown.
The examples in the Figure below illustrate three different ways in which a four CPU mainframe CPU complex can be provided for the use of a mainframe operating system such as z/OS.TM
Fig. 2.2: Three Ways to Provide Four CPUs for z/OS
The first example shows a traditional four processor hardware mainframe. It provides, rather clearly, four CPUs for z/OS.
The second example shows how VM can be used on a traditional hardware mainframe to provide four CPUs. Because VM virtualizes the processors of its host mainframe, the number of CPUs it can provide is not linked to the number of CPUs of its host. In this example, VM provides four virtual CPUs when its host mainframe has only two physical CPUs.
The third example shows how FLEX-ES can be used on an IA-32 server to provide four CPUs.
As will be discussed later, with FLEX-ES there must be a one-to-one correspondence between emulated the CPUs and server processors of any FLEX-ES "Instance" (although multiple Instance may share server processors). Thus, a FLEX-ES system which is to provide a four CPU Instance must itself have at least four server processors. The principles and details of the relationship between FLEX-ES emulated CPUs and host server processors will be discussed in a later chapter.
At this point, however, the important concept to grasp is that from the z/OS perspective above the "architectural line" (shown as a heavy horizontal line through all three examples) each of these three solutions is indistinguishable from the others. There is, in particular, no direct interaction between the FLEX-ES server's operating system (UnixWare®, Linux®) and the mainframe operating system. FLEX-ES does not, for example, run z/OS processes directly; neither does z/OS determine how work runs on the server. FLEX-ES provides an emulated machine, and z/OS runs on that emulated machine.
The next Figure, below, illustrates a more complex situation. These examples show the provision of three CPUs for the use of two separate mainframe operating systems (say, a single CPU for VSE and two CPUs for z/OS). This may be done in at least three ways.
Fig. 2.3: Three Ways to Provide CPUs for Two Mainframe OSs
On the left in this example, a hardware mainframe with the IBM's PR/SM (Processor Resource/Systems Manager) Facility provides two LPARs (Logical Partitions), within which the three CPUs are provided as appropriate.
In the middle, VM simply virtualizes the processors of a traditional hardware mainframe to provide three processors for what would be termed two "guest" operating systems.
On the right, two "Instances" (think: invocations) of FLEX-ES provide two emulated mainframes. Each is complete (emulated) computer, logically independent from the other. One is a single-processor mainframe, on which in this example VSE runs. The other is a dual-processor mainframe, running z/OS. There is, again, a one-to-one correspondence between the emulated mainframe CPUs and server processors. This correspondence will be discussed in detail in later chapters.
From the mainframe OS perspective above the "architectural line," these three solutions are indistinguishable.
Those who have been introduced to FLEX-ES first on the basis of its capabilities (e.g., "run mainframe work on a server") initially may mistake it for other kinds of server-based mainframe software. It is therefore important to clarify several things which FLEX-ES is not.
FLEX-ES is not an implementation or clone of any mainframe operating system or any part of any mainframe operating system. Neither does FLEX-ES require the modification of any mainframe operating system or mainframe application. As noted above, FLEX-ES is a mainframe computer. The mainframe operating system (z/OS,® VSE,® z/VM,® Linux®/390, etc.) and mainframe applications run on the FLEX-ES mainframe computer just as they would run on any traditional hardware-based mainframe.
It is therefore not meaningful to ask if FLEX-ES supports particular system services provided by mainframe operating systems. If for example a user has an application that requires the VSAM access method, and that user asks if FLEX-ES "supports VSAM," the strict answer is no, it does not. This does not mean that the user's application cannot be supported on a FLEX-ES mainframe, though. It simply means that the user has asked the wrong question. FLEX-ES provides a mainframe on which runs an operating system such as OS/390 which provides VSAM. The user's application runs on top of this operating system.
By way of analogy, a highway does not itself support air conditioning, yet air conditioned vehicles may certainly run on it.
FLEX-ES is not a server-based mainframe cross-compiler or cross-assembler. Neither is it an implementation on a server of the look and feel of a mainframe environment. It is a mainframe computer. Real mainframe compilers and assemblers run on the mainframe operating systems which in turn run on FLEX-ES. Similarly, these mainframe operating systems and their system software and applications provide the mainframe work environment.
This diagram illustrates the relationships between many (but not all) FLEX-ES components and their server and mainframe environments.
Fig. 2.4: Components
Instances must be defined as being in one of several distinct architectural levels: z, esa, 370, or vse. All mainframe CPUs within an Instance run in the same architectural level. Different Instances may run simultaneously at different architectural levels.
To define an Instance as 64-bit z/Architecture,TM use the following statement in the system declaration which defines the Instance in a Resource configuration file:
instset(z)
To define an Instance as 31-bit z/Architecture, use the esa architectural level.
In z mode (64-bit z/Architecture mode) one optional feature may be specified. Optional features are discussed in greater detail in the volume FSIMM310: Resource Language Reference. The optional feature valid for z mode is:
Only one mode, esa is provided to accommodate
To define an Instance as esa use the following statement in the system declaration which defines the Instance in a resource configuration file:
instset(esa)
Several optional features are provided. These are discussed in greater detail in the volume FSIMM310: Resource Language Reference. These features include:
(Note: VM/ESA 2.2.0 and older releases of VM/ESA ESA feature CP require System/370 mode SIE features in order to IPL. The absence of these features will result in a disabled wait state "9030" if an attempt is made to IPL. VM/ESA 2.3.0 and later do not require these features to IPL. These features are not enabled by default in FLEX-ES, but may be enabled through the use of "feature enable370".)
370 To define an Instance as (System/370), use the following statement in the system declaration which defines the Instance in a resource configuration file:
instset(370)
A multiprocessing System/370 level Instance may have a maximum of two mainframe processors.
Several optional features are provided. These are discussed in greater detail in the volume FSIMM310: Resource Language Reference. These features include:
To define an Instance as vse (ECPS:VSE), use the following statement in the system declaration which defines the Instance in a resource configuration file:
instset(vse)