systems and security folks. This is not to say that differences do not exist, just that they are minor and should not be perceived by most end users. QMF users should see virtually no differences. The one possible exception is the TRANSLATE scalar function which is not supported by DB2.

8.2.1.2 Application Developers

While end users will see little or no differences, application developers can expect to see more differences between the two products. However, it is important to realize that the basic job of developing an application is the same.

Developers can use the same design process.

The method of making an SQL call in a program is the same (through the use of the EXEC SQL statement).

The operators - DECLARE, OPEN, FETCH and CLOSE - are the same. These are statements used in application programs to handle cursors.

Application program preparation using precompile and bind is essentially the same - very few differences.

Both products have facilities to enter one or more SQL statements at a terminal for execution against a relational database. This could be done for testing or to do some work without having to write a program, for example, a one time requirement. In SQL/DS this facility is called ISQLthat runs under CICS/VSE and in DB2 it is called SPUFIand runs under ISPF in TSO. SPUFI does not have the limited answer set formatting and printing capability of ISQL.

Application developers should consider that while the program preparation process is similar, some differences exist. For example, DB2 preparation occurs in two phases - precompile and bind. For SQL/DS both phases are done in the same step. Because of DB2s separation of these functions, the database does not need to be available during the precompile phase. SQL/DS does have the ability via the DBSU to UNLOAD and LOAD packages. DB2 does not have a utility capable of unloading and loading a package. If you are using this SQL/DS capability, you will need to save the DB2 DBRM or preprocess the program again to create the DB2 DBRM.

For application programming languages, DB2 supports all of the languages supported by SQL/DS except RPG. It should be noted however, that SQL/DS V3R5 was the last release which provided this support; it was dropped in V5.

There are some minor variations in the application programming interfaces for the two products. For example, the meaning of SQLCODE values other than 100, 0, -803, and -911 is product specific. Thus, how an application programs logic handles SQLCODEs other than these will need to be examined and modified appropriately. A major improvement was provided with the introduction of DB2/VSE V5: SQLSTATEs are now at the SQL92 level as is DB2/OS390. That means that an application can use the SQLSTATE to determine an error and that the SQLSTATE is no longer platform specific.

Besides differences in SQL return codes, other differences exist in the SQLCA (SQL Communications Area) following a negative SQL return code. The SQLCA has a number of fields that indicate the condition of the most recently executed SQL statement. You should update your program logic that processes, records, and displays this information.

Chapter 8. Databases 179

Page 203
Image 203
IBM OS/390 manual Application Developers

OS/390 specifications

IBM OS/390, a versatile operating system, was a cornerstone in enterprise environments and played a pivotal role in mainframe computing. Released in the mid-1990s, OS/390 combined the strengths of IBM's MVS (Multiple Virtual Storage) with new features and enhancements, targeting scalability, reliability, and performance in demanding business applications.

One of the key features of OS/390 was its robust support for multiple users and processes. The system allowed thousands of concurrent users to access applications and data, ensuring high availability and minimizing downtime—a critical requirement for many large organizations. This scalability was supported through various enhancements in memory management and processor scheduling, enabling optimal resource allocation across diverse workloads.

OS/390 was known for its superior workload management capabilities. The Workload Manager (WLM) component allowed administrators to define service policies, specifying how system resources would be allocated according to the priority of tasks. This ensured that critical business processes received the necessary resources while less critical tasks were managed more flexibly.

Another significant characteristic of OS/390 was its commitment to security. The operating system provided comprehensive security features, including user authentication, data encryption, and auditing capabilities. This focus on security was vital for organizations handling sensitive data, ensuring compliance with regulations and safeguarding against unauthorized access.

OS/390 also supported advanced technologies that facilitated integration and development. The system included features like the IBM CICS (Customer Information Control System) for transaction processing and IMS (Information Management System) for database management. These technologies allowed organizations to build robust, high-performance applications tailored to specific business needs.

The ease of network integration was another strength of OS/390. With the advent of the Internet and global connectivity, OS/390 systems could easily interface with various network protocols, enabling businesses to operate in a connected world. This inclusion paved the way for many organizations to expand their capabilities and offer new services, driving digital transformation.

In conclusion, IBM OS/390 represented a significant advancement in mainframe technology, combining scalability, security, and robust workload management. Its rich feature set and support for critical enterprise applications solidified its role as a vital component of many organizations' IT infrastructures, ensuring they could meet their operational challenges head-on while supporting future growth. As technology continues to evolve, the legacy of OS/390 remains influential in the realm of computing.