Designing an application for z/OS

During the early design phases, the application designer makes decisions regarding the characteristics of the application. These decisions are based on many criteria, which must be gathered and examined in detail to arrive at a solution that is acceptable to the user. The decisions are not independent of each other, in that one decision will have an impact on others and all decisions must be made taking into account the scope of the project and its constraints.

Designing an application to run on z/OS® shares many of the steps followed for designing an application to run on other platforms, including the distributed environment. z/OS, however, introduces some special considerations. This section provides some examples of the decisions that the z/OS application designer makes during the design process for a given application. The list is not meant to be exhaustive, but rather to give you an idea of the process involved:

Designing for z/OS: Batch or online?
Designing for z/OS: Data sources and access methods
Designing for z/OS: Availability and workload requirements
Designing for z/OS: Exception handling.

Beyond these decisions, other factors that might influence the design of a z/OS application might include the choice of one or more programming languages and development environments. Other considerations discussed in this section include the following:

Using mainframe character sets
Using an interactive development environment (IDE)
Differences between the various programming languages.

Keep in mind that the best designs are those that start with the end result in mind. We must know what it is that we are striving for before we start to design.

Designing for z/OS: Batch or online?

When designing an application for z/OS and the mainframe, a key consideration is whether the application will run as a batch program or an online program. In some cases, the decision is obvious, but most applications can be designed to fit either paradigm. How, then, does the designer decide which approach to use?

Reasons for using batch or online:

Reasons for using batch:
- Data is stored on tape.
- Transactions are submitted for overnight processing.
- User does not require online access to data.
Reasons for using online:
- User requires online access to data.
- High response time requirements.

Designing for z/OS: Data sources and access methods

Here, the designer's considerations typically include the following:

What data must be stored?
How will the data be accessed? This includes a choice of access method.
Are the requests ad hoc or predictable?
Will we choose PDS, VSAM, or a database management system (DBMS) such as DB2®?

Designing for z/OS: Availability and workload requirements

For an application that will run on z/OS, the designer must be able to answer the following questions:

What is the quantity of data to store and access?
Is there a need to share the 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 (24 hours a day 7 days a week or 8:00 AM to 5:00 PM weekdays, and so on)?

Designing for z/OS: Exception handling

Are there any unusual conditions that might occur? If so, we need to incorporate these in our design in order to prevent failures in the final application. We cannot always assume, for example, that input will always be entered as expected.