8.2.1.3 Database Administrators (DBAs)

As with the previous two groups discussed, there are really more similarities than differences between the two products for the DBA. The design methodology is the same, whether you prefer normalization or some other technique. The optimizer selects access paths basically the same way, relieving the DBA from making this choice. Differences show up in some of the detail work of database design. Differences exist in the areas of database object sizes, SQL limits, locking levels, DRDA considerations, referential integrity definitions, and data formats. SQL/DS is a subset of DB2 in these areas except an SQL/DS table definition can contain one or more LONG VARCHAR columns that could materialize an actual row length that exceeds the 32K limit of a DB2 row. If you do have this situation, you will need to redesign this table to fit within the 32K row limit of DB2 and modify the programs appropriately that use this data.

8.2.1.4 System Administrators

There are more differences in this area than in the previous areas. This is primarily due to environmental differences in the VSE and the OS/390 platforms. Both systems provide the entire complement of systems management, utilities and integrity services expected of a robust RDBMS. However, implementation may be different.

In both systems, normally all database changes caused by the execution of SQL statements are logged. However, when running SQL/DS in a single user environment this logging is optional and when you have an SQL/DS storage pool with the NOLOG attribute this logging is not done. Both of these capabilities are not available in DB2 and will have to be evaluated and mapped to a different DB2 implementation.

Since recovery capabilities and procedures are very different between SQL/DS and DB2, you must re-evaluate your needs and design a recovery procedure using the DB2 facilities. This also applies to Utilities.

The following is provided to help you in mapping SQL/DS utility functions to DB2 utility functions:

Reorganize a table

￿SQL/DS - DBSU UNLOAD/RELOAD

￿ DB2 - REORG utility

Update table statistics

￿SQL/DS - UPDATE STATISTICS SQL statement

￿ DB2

- RUNSTAT utility

Load data into a table

￿SQL/DS - DBSU LOAD

￿ DB2

- LOAD utility

Unload data to a user defined sequential file

￿SQL/DS - DBSU DATAUNLOAD

￿ DB2

- not supported

While both SQL/DS and DB2 operate from the same relational basis of viewing data as tables, the underlying storage structures used differ. At the logical level, a DB2 database is composed of one or more tablespaces which in turn are composed of one or more tables, and indexspaces, which contain one index. In SQL/DS, both tables and indexes are stored together in dbspaces.

180VSE to OS/390 Migration Workbook

Page 204
Image 204
IBM OS/390 manual Database Administrators DBAs, System Administrators, SQL/DS Dbsu UNLOAD/RELOAD, SQL/DS Dbsu Load

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.