Comparison of the Environments

Now that you have learned about each environment in which DB2 programs can execute, you can begin to compare their features and capabilities. When choosing an operating environment for a DB2 application, you should ensure that it can support the data needs of the application. Typically, a corporation's data is spread across disparate processing platforms and data storage devices. Additionally, the data is stored in many different physical manifestations .

When you're choosing an environment for your application, consider the following:

• Do you have access to the environment that you want to use for a development platform? If not, can you obtain access?

• Can you access data key to your enterprise in the format in which it exists today, or will your choice of environment require that the data be duplicated and placed in a readable format?

• Are the programmers who will be working on the project knowledgeable in the chosen environment, or will extensive training be required?

Resource Availability

Table 18.10 presents resource availability categorized by each processing environment that has been discussed. You can use this table as a reference when deciding on a processing environment for your DB2 applications.

Table 18.10. A Comparison of Resource Availability

Resource	CICS	TSO Online	TSO Batch	CAF	RRSAF	IMS MPP	IMS Fast Path	IMS BMP	DL/I Batch
Flat file access	Yes	Yes	Yes	Yes	Yes	No	No	No [*]	Yes [*]
VSAM access	Yes	Yes	Yes	Yes	Yes	No	No [**]	No [**]	Yes [**]
Online IMS database	Yes	No	No	No	No	Yes	Yes	Yes	No
Offline IMS database	Yes	No	No	No	Yes	No	No	No	Yes
Invoked by JCL	No	No	Yes	Yes	Yes	No	No	Yes	Yes
Invoked by transaction	Yes	No	No	No	No	Yes	Yes	No	No
Invoked by CLIST or REXX EXEC	No	Yes	No	Yes	Yes	No	No	No	No
Invoked by ISPF	No	Yes	No	No	Yes	No	No	No	No

^[*] IMS GSAM database

^[**] IMS SHISAM database

You might find some of the entries in Table 18.10 confusing. The following explains these entries in more detail:

• Yes indicates that the processing environment listed across the top can access the resource defined along the left. Simply because the resource is accessible (as IBM delivers the products that support the environment), however, does not mean that you can use it in your shop. Some shops restrict and limit access, so consult your shop standards before proceeding with development plans based on Table 18.10.

• Flat file access is available using IMS calls when a GSAM (Generalized Sequential Access Method) database is defined for the flat file. IMS BMPs and batch programs can access flat files as GSAM databases. Access to flat files using pure OS/VS reads and writes is available only to IMS batch programs.

• All IMS programs can access VSAM KSDS data sets as a SHISAM (Simple Hierarchic Indexed Sequential Access Method) database. Again, IMS batch programs are the only type of IMS program that can access a VSAM file using VSAM data set commands.

• IMS online databases are those defined to the IMS control region and started for online access in IMS/TM. Conversely, an offline IMS database either is not defined under the IMS control region and is thus not accessible by IMS/TM, or it is stopped (sometimes referred to as DBR ed) to IMS/TM.

Feasibility

After ensuring that what you want is possible, your next step is to ascertain whether it is feasible. An application is feasible in a specified environment if the response time and availability requirements of the application can be met satisfactorily by the environment. Typically, you should draw up a service-level agreement for each new application, developing a price-to-performance matrix. Consider this example:

The online portion of the system must provide an average response time of x seconds, y percent of the time, for an average of z users. The cost per transaction is approximately a .

Use the information in Table 18.11 to determine which online environment is feasible for your project.

Table 18.11. Comparison of Online Development Capabilities

Characteristic	TSO	CICS	IMS/TM
Response time	Slow	Fast	Fast
Flexibility	High	Low	Low
Number of concurrent users	Fewer than 10	Many	Many
Overhead per user	Very high	Very low	Low
Program linking	Not easy	XCTL / LINK	Message switching
Online screen language	ISPF Dialog	BMS	MFS Manager
Screen development	Fast	Cumbersome	Cumbersome
Program development	Fast	Medium	Slow
Prototyping and testing tools	Many	Some	Few

As you ponder the choices of development environments for your DB2 applications, ask the following questions:

• What is the deadline for system development? What programming resources are available to meet this deadline? Do you have the requisite talent to develop the system in the optimal environment? If not, should you hire programmers or settle for a less than optimal solution?

• What are the performance requirements of the system? How many concurrent users will be using the system during peak processing time, and can the given environment support the workload?

Sometimes you have little or no choice. If a shop has only one environment, the decision is easy. If your shop has more than one environment, the right decision is never to confine yourself to only one environment. Each environment has its own strengths and weaknesses, and you should consider them in your application development solution.

When multiple environments are used to access DB2 data, they become inextricably wound in a critical mass. This situation can be difficult to administer and warrants consideration.

Batch Considerations

Although this chapter is primarily concerned with coverage of the online processing opportunities available to DB2, a quick discussion of the various batch processing options is in order. DB2 batch processing can be implemented using the following:

• DSN under TSO

• CAF or RRSAF

• Batch DL/I

• BMP under IMS/TM

In terms of performance, no significant differences exist among DSN , CAF, batch DL/I, and BMPs. However, if you need to squeeze every last bit of performance out of a batch application, consider these points:

• Because DSN uses TSO, you will have some additional overhead for TSO resources when compared to an equivalent CAF program.

• Because BMPs execute in an IMS control region, initialization will take longer than an equivalent DSN or CAF program.

• Commit processing tends to take longer for BMPs because they check for DB2 and IMS update activity.

Although performance differences are minimal, you will discover several coding implications:

• CAF and RRSAF programs require connection logic and error handling not required by DSN.

• IMS SYNCPOINT must be used in lieu of COMMMIT for BMPs.

• DL/I batch programs require coding for the DDITV02 data set.