1、 1Designing and developing applications for z/OS 8.1 Application designers and programmers The tasks of designing an application and developing one are distinct enough to treat each in a separate textbook. In larger z/OS sites, separate departments might be used to carry out each task. This chapter
2、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
3、depends in part on the designers knowledge of the business itself, awareness of other roles in the mainframe organization such as programming and database design, and understanding of the businesss hardware and software. In short, the designer must have a global view of the entire project. Another r
4、ole 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 sys
5、tems analyst requires a broad understanding of the organizations 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 th
6、e 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
7、 run on the mainframe for the end users. Based on the application designers 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
8、 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
9、 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 re
10、sponsible for maintaining and enhancing the companys 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 2have bec
11、ome popular for building new applications on the mainframe, just as on distributed platforms. 8.2 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, w
12、hich 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. De
13、signing 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 chapter provides some examples of the decisions that the z/OS application
14、 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? on page 258 _ Designing for z/OS: Data sources and access methods on page 258 _ Designing for z/OS
15、: Availability and workload requirements on page 258 _ Designing for z/OS: Exception handling on page 259 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 cons
16、iderations discussed in this chapter include the following: _ Using mainframe character sets in Using the EBCDIC character set on page 265. _ Use of an interactive development environment (IDE) in Using application development tools on page 267. _ We discuss differences between the various programmi
17、ng languages in Chapter 9, Using programming languages on z/OS on page 275. 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. 8.2.1 Designing for z/OS: Batch or online? When designing an ap
18、plication 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? Reas
19、ons for using batch or online: _ Reasons for using batch Data is stored on tape. 3 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. 8.2.2 Designing for z
20、/OS: Data sources and access methods Here, the designers 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 managemen
21、t system (DBMS) such as DB2? 8.2.3 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
22、 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)? 8.2.4 Designing for z/OS: Exception han
23、dling 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. 8.3 Application development life cycle: An overview A
24、n 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
