Application designers and programmers
Application programming on z/OS
The application designer gathers requirements from business systems analysts and end users. The application programmer is responsible for developing and maintaining application programs.
The tasks of designing an application and developing one are distinct enough to treat each in a separate learning module. In larger z/OS® sites, separate departments might be used to carry out each task. This section provides an overview of these job roles and shows how each skill fits into the overall view of a typical application development life cycle on z/OS.
The application designer is responsible for determining the best programming solution for an important business requirement. The success of any design depends in part on the designer's knowledge of the business itself, awareness of other roles in the mainframe organization such as programming and database design, and understanding of the business's hardware and software. In short, the designer must have a global view of the entire project.
Another role involved in this process is the business systems analyst. This person is responsible for working with users in a particular department (accounting, sales, production control, manufacturing, and so on) to identify business needs for the application. Like the application designer, the business systems analyst requires a broad understanding of the organization's business goals, and the capabilities of the information system.
The application designer gathers requirements from business systems analysts and end users. The designer also determines which IT resources will be available to support the application. The application designer then writes the design specifications for the application programmers to implement.
The application programmer is responsible for developing and maintaining application programs. That is, the programmer builds, tests, and delivers the application programs that run on the mainframe for the end users. Based on the application designer's specifications, the programmer constructs an application program using a variety of tools. The build process includes many iterations of code changes and compiles, application builds, and unit testing.
During the development process, the designer and programmer must interact with other roles in the enterprise. The programmer, for example, often works on a team of other programmers who are building code for related application modules.
When the application modules are completed, they are passed through a testing process that can include functional, integration, and system tests. Following this testing process, the application programs must be acceptance-tested by the user community to determine whether the code actually accomplishes what the users desire.
Besides creating new application code, the programmer is responsible for maintaining and enhancing the company's existing mainframe applications. In fact, this is frequently the primary job for many application programmers on the mainframe today. While many mainframe installations still create new programs with COBOL or PL/I, languages such as Java™ have become popular for building new applications on the mainframe, just as on distributed platforms.
Parent topic: Designing and developing applications for z/OS
Designing an application for z/OS
Application programming on 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.
Parent topic: Designing and developing applications for z/OS
Related information
The EBCDIC character set
Application development tools
Designing and developing applications for z/OS
Programming languages on z/OS
Application development life cycle: An overview
Application programming on z/OS
An application is a collection of programs that satisfies certain specific requirements (resolves certain problems). The solution could reside on any platform or combination of platforms, from a hardware or operating system point of view.
As with other operating systems, application development on z/OS® is usually composed of the following phases:
Design phase
Gather requirements.
User, hardware and software requirements
Perform analysis.
Develop the design in its various iterations:
High-level design
Detailed design
Hand over the design to application programmers.
Code and test application.
Perform user tests.
User tests application for functionality and usability.
Perform system tests.
Perform integration test (test application with other programs to verify that all programs continue to function as expected).
Perform performance (volume) test using production data.
Go into production–hand off to operations.
Ensure that all documentation is in place (user training, operation procedures).
Maintenance phase--ongoing day-to-day changes and enhancements to application.
Figure 1 shows the process flow during the various phases of the application development life cycle.
Figure 1. Application development life cycle
Application development life cycle
Figure 2 depicts the design phase up to the point of starting development. Once all of the requirements have been gathered, analyzed, verified, and a design has been produced, we are ready to pass on the programming requirements to the application programmers.
Figure 2. Design phase
Design phase
The programmers take the design documents (programming requirements) and then proceed with the iterative process of coding, testing, revising, and testing again, as we see in Figure 3.
Figure 3. Development phase
Development phase
After the programs have been tested by the programmers, they will be part of a series of formal user and system tests. These are used to verify usability and functionality from a user point of view, as well as to verify the functions of the application within a larger framework (Figure 4).
Figure 4. Testing
Testing
The final phase in the development life cycle is to go to production and become steady state. As a prerequisite to going to production, the development team needs to provide documentation. This usually consists of user training and operational procedures. The user training familiarizes the users with the new application. The operational procedures documentation enables Operations to take over responsibility for running the application on an ongoing basis.
In production, the changes and enhancements are handled by a group (possibly the same programming group) that performs the maintenance. At this point in the life cycle of the application, changes are tightly controlled and must be rigorously tested before being implemented into production (Figure 5).
Figure 5. Production
Production
As mentioned before, to meet user requirements or solve problems, an application solution might be designed to reside on any platform or a combination of platforms. As shown in Figure 6, our specific application can be located in any of the three environments: Internet, enterprise network, or central site. The operating system must provide access to any of these environments.
Figure 6. Growing infrastructure complexity
Growing infrastructure complexity
To begin the design process, we must first assess what we need to accomplish. Based on the constraints of the project, we determine how and with what we will accomplish the goals of the project. To do so, we conduct interviews with the users (those requesting the solution to a problem) as well as the other stakeholders.
The results of these interviews should inform every subsequent stage of the life cycle of the application project. At certain stages of the project, we again call upon the users to verify that we have understood their requirements and that our solution meets their requirements. At these milestones of the project, we also ask the users to sign off on what we have done, so that we can proceed to the next step of the project.
Parent topic: Designing and developing applications for z/OS
