At the physical level, in DB2 each tablespace is stored in a pageset, which consists of one or multiple VSAM ESDS data sets or LDSs. In SQL/DS, data is stored in storage pools that are composed of one or more dbextents. In VSE, a dbextent consists of one VSAM ESDS data set. While this may seem similar, the difference is that in DB2 one VSAM data set is used for only one tablespace. In SQL/DS, one VSAM data set can be used to store data from any or all tables in the system (within one storage group).

As a result of the different storage structures and names used, a new physical data model must be developed for the DB2 environment and then the parameters associated with storage structures in the data definition language (DDL) SQL statements must be updated to implement the new physical data model.

8.2.1.5 Security Administrators

Both products have the same set of table privileges (ALTER, DELETE, INDEX, INSERT, REFERENCES, SELECT and UPDATE). Other privileges related to the use of resources (such as using space by creating table) and operation (such as executing programs) are granted in a similar manner, but the definition of user types is different. Thus, there are different operands within the GRANT command. DB2 allows group authorization (not in SQL/DS, but in the new Control Center feature of DB2/VSE V5) so that fewer GRANT statements need to be issued.

Implementation is different in how users are given certain authority and each product has its own naming convention. Because the two products differ in how databases are defined and organized, the levels of authorization are more robust in DB2. In DB2, the highest level authority is called SYSADM and in SQL/DS, the equivalent level is called DBA. Some noteworthy differences in the SQLs are:

∙

∙

The VSE CONNECT statement can have ²user IDENTIFIED BY password², but the OS390 can not.

Tables on VSE can specify CCSIDs at the column level. Current (for DB2/OS390 V5) CCSIDs can only be specified at the table level. So if the VSE customer is utilizing this, they will need to convert their data to use a common CCSID in the table.

When DB2 is installed, only users with SYSADM authority have the SELECT privilege on catalog tables. With SQL/DS, upon initial install all users have SELECT privilege on catalog tables. In DB2, SYSADM and other users granted the proper authority can update catalog statistics used by the optimizer in access path selection. In SQL/DS, DBA authority includes all table privileges on catalog tables. The tables in the catalog are organized differently in the two products. Therefore, catalog queries will be incompatible between the two.

8.2.2Other Comparison Areas

8.2.2.1Year 2000

DB2 for OS/390 Version 5 is Year 2000 compliant. For DB2 for MVS/ESA Versions 3 and 4, you need to apply an APAR for Year 2000 compliance. For more details, get the DB2 and the Year 2000 White Paper from the Web. Its URL is:

Chapter 8. Databases 181

Page 204 Page 206
Page 205
Image 205
IBM OS/390 manual Other Comparison Areas, Security Administrators, Year
Page 204 Page 206

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.
Top Page Image Contents