Tips for z/OS Application Development

Tips for z/OS Application Development

Applications that aren't available and performing well are not an asset to an organization. Poorly performing mainframe applications cost significantly more than efficient, properly tuned ones.

The majority of tuning efforts are made at the operating system and database level. But the largest performance gains are often obtained from tuning application code. And performance, no matter how good, can always be improved.

These tips should help.

The Basics, First

An application is a collection of computer programs that satisfies certain specific requirements, or resolves certain problems.

Computer applications work on data, which needs to be accessed from either local or remote locations. The applications manipulate the data, performing some kind of processing on it, then present the results.

Application development on z/OS usually consists of several phases.

1. The Design Phase

The application designer must establish the best programming solution for any given business requirement. He/she must have a global view of the entire project: a knowledge of the business itself, awareness of other roles in the mainframe organization (such as programming and database design), and an understanding of the business’s hardware and software.

The designer must gather requirements from business systems analysts and users, then determine which IT resources will be available to support the application. He/she then writes design specifications for the application programmers to implement.

Any one decision will have an impact on others, and all the decisions made must take into account the scope of the project and its constraints.

The best designs are those that start with an end result in mind.

Batch, or Online?

In designing for z/OS, a key consideration is whether the application runs as a batch program or an online program.

Batch programs should ideally be used when transactions need to be submitted for overnight processing, or when data is to be stored on tape.

The online approach is best when users require online access to data, or if quick response times are required.

Other factors that might influence the design of a z/OS application include the choice of one or more programming languages, and development environments.

Data Sources and Access Methods

Application design must take into account what kind of data is to be stored, and how it will be accessed. Requests for data may be predictable or ad hoc, and this will influence both the storage and access methods – whether PDS, VSAM, or a database management system (DBMS), such as IMS or DB2.

Workloads and Availability

Design should ask and answer the following questions:

  • How much data do we need to store and access?
  • Is there a need to share that data?
  • What are the response time requirements?
  • What are the cost constraints of the project?
  • How many users will access the application at once?
  • What is the availability requirement of the application?
  • Are there any unusual conditions that might occur? If so, incorporate these into the design to prevent failures in the final application.

2. Coding and Testing

Based on the designer’s specifications, the application programmer builds, tests, and delivers application programs, using a variety of tools. The build process involves many iterations of code, with changes and compiles, application builds, and unit testing. Development often involves interaction with other programmers in an enterprise who are building code for related application modules.

When the application modules are complete, they must go through a testing process that can include functional, integration and system tests. After this, the application programs must be acceptance-tested by the user community to determine whether the code actually accomplishes what it was designed for.

  • Code and test the application itself.
  • Perform user tests. Have users evaluate the application for functionality and usability.
  • Perform integration tests. Test the application with other programs to verify that all programs will continue to function as anticipated.
  • Conduct performance or volume tests using actual production data.

3. Production and Hand-off

Before going to production, the development team must provide proper documentation. Ensure that all materials are in place, to cover user training (which familiarizes users with the new application) and operational procedures.

The operational procedures documentation must enable operations to take over responsibility for running the application on a day-to-day basis.

4. Maintenance

The maintenance phase of an application's lifecycle involves ongoing changes and enhancements to the application. The programming group responsible for this should ensure that all changes are tightly controlled and rigorously tested before being moved into production.

Design for Different Platforms

System components may be spread across different machines or different platforms, each performing its work in a server farm environment. Unlike the mainframe, distributed applications are usually not designed with resource conservation in mind.

The IBM System z approach is for applications to be maintained using tools residing on the mainframe. Some of these make it possible to have different platforms sharing resources and data in a coordinated and secure way, according to workload or priority.

Rational Developer for System z (RDz), IBM’s z/OS Eclipse-based software development IDE makes possible traditional application maintenance and enterprise modernization via a 21st century GUI, ideal for those new to the mainframe.

Applications Wish-List

Aim for these qualities:

Accessibility

Recoverability

Serviceability

Availability

Security

Connectivity

Usability

Frequency of data backup

Portability

Web services

Changeability

Failure prevention and fault analysis

And always keep in mind the goals which the application is being designed to accomplish.