Data processing applications use combined functions to perform a task. An application system design is a collection of combined functions used to perform a job. Each function calls for a single, well-defined action. Individual program designs within the application system also require a collection of related functions. Detail increases on the program level.

Program Specifications

Studying the need your application will fill is the first step in program design. Develop the complete requirements and specifications that state the program objectives. Specifications for an application program should describe in detail the three main parts of the program:

  • Input - What goes into the program
  • Process - What changes take place in processing this data
  • Output - What results are achieved



Your computer installation probably has a set of programming standards and guidelines to promote consistency among programs and applications. These standards make it easier to maintain programs.

Hardware and Software Considerations

As you design your application program, consider the hardware and software available to you and to end-users. Questions to ask in the design stage are, for example:

  • Which operating system: MVS or CMS?
  • Which storage media: Tapes, disk, or cards?
  • Which access method: VSAM or QSAM?
  • Which input device for program development and execution: Terminal or cards? Input facilities for special characters or graphics?
  • Which output facilities available for program development and for program execution: Terminal, printer, DBCS or special graphics printer, tape, disk, or cards?
  • Which licensed programs will you use with VS COBOL II?

Designing for Ease of Use

Design your program with the end user in mind. Ease of use is more important than ease of programming. Be sure you know the answers to the questions in 'Hardware and Software Considerations' before you start your design. As you expand your design, you will need to answer the following additional questions for interactive programs:

  • Will more than one person use the program at a time? An application might require many users to execute a program at the same time. A program that will be shared in this manner must be reentrant. With reentrant code, each end user is unaware of and unaffected by other users. Reentrant programs must be compiled using the RENT and RES options (also NODYNAM, if using CICS).
  • Will the program be called as a subprogram by a non-COBOL program? A program that is loaded and deleted by a non-COBOL program during execution of the run unit must be reentrant. Reentrant programs must be compiled using the RENT and RES options.
  • Will there be any terminal-directed I/O?
  • Under which interactive system will the program run? IMS/VS, IMS/ESA, CICS/MVS, CICS/ESA, C1CS/VM, TSO, CMS, or a user-written system? Plan for preprocessing, compile requirements, naming, and documentation. If possible, investigate the user's specific plans for input and output.
  • What kind of errors might the user make? At the design stage, decide whether a program will continue running after a less-than-severe I/O error or other kinds of incorrect input. Specifications for an application program should describe the three main parts of the program: input, process, and output.

Planning the Input

When planning the input, include in your specification answers to these specific questions:

  • Does the input data already exist? If so, what is its format? If not, what record layout would be easy for the end user to process to get the desired results?
  • Where will the input data come from? Will the data be passed from another program? How? Will the data be coming from an online system or from a batch system?
  • How will the data be entered? From a terminal? From a tape or disk file?
  • What will the input data look like?
  • What initial editing will you need to do?
  • What record format and file organization is best for your application program?
  • What access method will you use?
  • What are the size and type of each input value?
  • What validity checks are performed on this data?

Planning the Process

When planning the process of your program, include the following considerations in your specifications:

  • The flow of the program
  • How the program works with other modules in the run unit
  • The computational algorithms, if any
  • The functions, subroutines, and subprograms used, if any
  • The dependencies on input and output
  • The overall logic of the program

Planning the Output

When planning the output, include in your specifications answers to these specific questions:

  • What information does the end user need?
  • What comments or explanatory text should appear on the reports?
  • How many reports will the program created?
  • How will the printed results be formatted?
  • Will you use preprinted forms?
  • Should intermediate results be printed or stated?
  • Where the final results should be printed or stored?
  • Will the results of this application program be used as data for another program?
  • Will the program require specific output devices? For example: acolor terminal, special graphics terminal, disk, tape, or cards?

Designing for Simplicity

You can make the development process easier if you check for the following:

  • Is part of your program a typical COBOL task?
  • Has someone else written a similar program?
  • Can your program call or copy parts of an existing program to perform part of the job?
  • Can you use file or record descriptions from a COPY library? You can simplify your program by:
  • Grouping major functions
  • Identifying common sub-functions
  • Designing the tests, loops, calculations, and moves carefully

Sometimes an application is simple enough that it can be coded as a single, self-sufficient program. More often, however, an application's solution will consist of more than one program; these coordinated programs that make up the solution are bound together as one run unit. When deciding on how to separate your program into modules, you should be concerned with factors like function, size, independence etc.

If your program executes under an environment with extended addressing capabilities, the size restrictions on the data you process have been almost eliminated. However, structuring your modules according to function should be your primary motivation for separating your application solution into subprograms.

Efficient File Organization and Management

Plan how the files will be created or defined so that processing them will be most efficient. You need to know:

  • File type and organization (QSAM or VSAM)
  • Access modes (sequential, random, or dynamic)
  • Devices (there are some language dependencies)
  • Record formats (fixed, variable, spanned, undefined)

File Type and Organization

Depending on the input/output requirements and device types, your file organization will be sequential, indexed, or relative. You should decide on the devices and file types to be used when you design your program. QSAM and VSAM are the two access methods available with VS COBOL II that will handle the input/output requests to the operating system for the storage and retrieval of records from the input/output devices. Sometimes, the file processing method has been determined for you by the specifications for your application program or by your installation's standards. But, if the decision is yours, you need to consider several things:

  • If a large percentage of the file is referenced or updated in your application program, sequential processing is faster than indexed or relative. If a small percentage of records is processed during each run of your application program, use indexed or relative access.
  • A QSAM or VSAM sequential file is the simplest file type. Either works for an application that uses only sequential access of fixed-length or variable-length records and no insertion of records between existing ones.
  • A VSAM indexed file is the most flexible data set. It may be used for applications requiring, both sequential and random access in the same program. An indexed file can make use of fixed-length or variable-length records.
  • A VSAM relative file works well for an application that performs random insert and delete operations. A VSAM relative file can make use of fixed-length or variable-length records.

Summary of File Organizations, Access Modes, and Record Lengths

Summary of File Organizations, Access Modes, and Record Lengths

We will now see the different file organizations—sequential, indexed, relative, file organization for sequential-only devices and file organization for DASD.

  • Sequential File Organization - The arrangement of records is established by the physical order in which they are entered when the file is created. Each record (except the first) has a unique predecessor record, and each record (except the last) has a unique successor record. Once established, these relationships do not change. The record transmission (access) mode allowed for sequential files is sequential only.
  • Indexed File Organization - Each record in the file contains a field and the contents of that field form the record key. The position of this key field is the same in each record. The index component of the file provides the logical arrangement of the main file, ordered by record key. The actual physical arrangement of the records in the main file is not significant to your COBOL program. An indexed file can also make use of alternate indexes-keys that let you access the file using a different logical arrangement of the records. The record transmission (access) modes allowed for indexed files are sequential, random, or dynamic. When indexed files are read or written sequentially, the sequence is that of the key values.
  • Relative File Organization - Records in the file are identified by their location relative to where the file begins. The first record in the file has a relative record number of 1, the tenth record has a relative record number of 10, and so forth. The file can be thought of as a series of slots, each of which is numbered consecutively, and each of which may or may not hold an actual record. The record transmission (access) modes allowed for relative files are sequential, random, or dynamic. When relative files are read or written sequentially, the sequence is that of the relative record number.
  • File Organization on Sequential-Only Devices - Terminals, printers, card readers, and punches are called unit-record devices. They work a "line" at a time. After that line is processed, it exits the device. Therefore, you must work sequentially with each record as it is presented to your program or as your program sends it out. On a tape, the records are always arranged sequentially, and your program must process them sequentially. Use QSAM sequential files. The records on tapes can be fixed or variable in length, and the rate of data transfer is faster than it is for cards.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics