Welcome to z Systems™ Platform Test, also known as Integration Test. We'd like to explain to you exactly what we mean by "integration test" and how that concept works for z/OS and Linux. We'd also like to introduce you to the z Systems Platform Evaluation Test Team.
The concept behind Integration Test is pretty simple: if two software products are going to run together on the same operating system platform, they have to be tested together with a focus on their interactions.
When you're working with an operating system such as z/OS or Linux, the testing becomes considerably more complex—and considerably more important—but the concept is the same. All the elements and features of z/OS must work together and because nobody runs just an operating system, we have to make sure it works with a multitude of other products and functions.
At IBM, product testing is extensive. Integration test is not a replacement for the traditional test phases:
These test phases mainly focus on an individual product or function, or on a subset of products and functions. To further enhance quality, we built on the foundation provided by unit, function, and system test by adding an additional test effort—Integration Test. With Integration Test, there's greater emphasis on the customer experience, cross-product dependencies, and sensitivity to end users.
z Systems Platform Test is the final verification of a z/OS release prior to its becoming generally available to customers. It ensures that all elements and features of z/OS work seamlessly together and can support true production, mission-critical work. It also must provide all the industrial-strength z/OS advantages you're depending on: reliability, availability, serviceability.
We validate the z Systems software platform in the same manner customers use it. That means doing much more than just ensuring that products work together. We understand what it takes to introduce, implement, and effectively use new products and functions in a full production environment. Customers are expecting constant availability so we test the solution from their point of view, so we can hopefully save you some pain!
We document the results of our testing (including any pain we've experienced and how you can avoid that pain) in either our blog if it happened in the z/OS V2R1 timeframe or in our test reports if it happened in z/OS V1R13 or earlier. We provide tested examples, both in our blog, our test reports and here on our Web site, that span multiple products and have been run in what we call a pseudo-production environment.
We endeavor to provide you with the most stable operating system platform available in the marketplace—z/OS.
So, what do we mean by a pseudo-production environment? Well, we've set ourselves up to be as customer-like as possible. Our team is organized in a way that many IT shops are, and our team members take on the roles of system programmers, operators, database administrators, and so on. We focus on providing availability of applications to end users, and we pay attention to service level agreements and performance objectives. We look at the recovery aspects and behavior of our systems from an end user's perspective.
Our goal, like yours, is to have our workloads up 24 hours a day, 7 days a week (24 x 7). We have workloads that exercise the sysplex, networking, and application enablement characteristics of our configuration. For details about our workloads, see the Our Workloads topic in our test reports.
The primary focus of the z Systems Platform Evaluation Test team for z/OS and Linux Virtual Servers has been to run a data sharing Parallel Sysplex on the z Systems platform in as much of a customer-like fashion as possible.
As the operating system platform has evolved over the years, from MVS/ESA to OS/390 to z/OS, our mission has also expanded and, as a result, we have developed somewhat of a dual personality.
The Base Team is responsible for system programming, product support and testing of:
The Base Team is also responsible for:
The Base Team also focuses on the security-related elements and features of z/OS, which include:
The team also focuses on other security-related products on the z Systems platform, such as:
For interoperability testing, the security team also focuses on security-related products on non-z Systems platforms. These products include LDAP and Kerberos. The operating systems on which these products run include AIX®, Linux, and Microsoft Windows™, although not all of the products run on every operating system.
Additional responsibilities include:
The Middleware and Testware Team supports the following products that are not elements or features of z/OS but that run on the z/OS platform: CICS, DB2, IMS, IRLM, MQ, RLS, and WebSphere Application Server. These products drive our mission-critical online transaction processing (OLTP) workloads, which are all Parallel Sysplex data sharing workloads.
From a middleware perspective, our responsibilities include:
We are also responsible for the strategy, design, and development of applications that drive our z/OS base and middleware software. Our software architects, designers, developers, and application programmers work together to create, deploy, and maintain our mission-critical OLTP and exploit emerging technologies.
From a testware perspective, our responsibilities include:
The Linux team tries to emulate leading-edge customer environments, workloads, and activities. This includes cloning Linux images on z/VM and establishing security in a heterogeneous Linux server environment
In addition to the z/OS elements, the Linux team uses the following software in their day-to-day operations: z/VM, Linux on z Systems, WebSphere Application Server, WebSphere Application Sever Network Deployment (including Edge Components), Tivoli Access Manager for e-business (TAM), TAM WebSEAL, Tivoli Risk Manager, TrendMicro ScanMail, TrendMicro ServerProtect, iptables, z/OS LDAP and z/OS RACF, DB2, Apache plus z Systems hardware cryptographic acceleration, and various other open source security products.