Evento 18 giugno - IBM DB2 for i 7.2
0 likes395 views
The document discusses enhancements in DB2 for i version 7.2, including: - Added capabilities to enhance data protection, modernize legacy applications, and improve data access and management performance. - The enhancements fall under strategic focus areas of security, scalability, standards, and data analysis. - New features include row and column security controls, workload scalability improvements, SQL enhancements, and improved data analysis tools.
Evento 18 giugno - IBM DB2 for i 7.2
- 1. Introduction On April 28, 2014, IBM announced IBM i 7.2, a new version of the popular operating system that includes DB2 for i. This version of DB2 for i adds additional capabilities to: ・ Enhance protection of data through access rules and masking techniques ・ Extend legacy application code by modernizing DB2 for i usage ・ Improve performance of accessing and managing data in DB2 for i ・ Improve productivity of developers with powerful SQL enhancements
- 12. Multi‐action SQL Triggers As the utilization of SQL Triggers continues to arise, some developers are being challenged by the fact that they must define a separate SQL trigger for each database event that want to associate with a trigger. The new OR keyword on the BEFORE clause enables a developer to define multiple events for the SQL Trigger to process. In this example, the SQL Trigger is defined for all of the available events – Insert, Update, and Delete. A multiple-event trigger is not allowed to mix the trigger time. For example, this means that a single multiple-event SQL trigger cannot handle both Before and After events. Only a single trigger time value of Before, After, or Instead Of can be specified on multiple event SQL Trigger. The multiple-event trigger feature also includes new DB2 predicate support, so that the trigger logic can determine if the trigger is being called to process an insert, update, or delete event. The names of the new predicates are: INSERTING, UPDATING, and DELETING. These predicates are boolean variables that can be referenced on any conditional construct. This example references all 3 of new predicates, so that employee stats are incremented on insert operations and decremented on delete operations. For update operations, a threshold check is performed to ensure that an increase in salary doesn’t exceed company guidelines. Often stored procedure calls are used in combination with multiple-event SQL triggers, to minimize how often an SQL trigger must be recreated. The trigger logic is contained within the stored procedures. This enables only the stored procedure containing the trigger logic to be re- created when the trigger logic needs to be updated. As discussed earlier, avoiding the
- 13. recreation of an SQL trigger means that you reduce the number of times that DB2 must obtain an exclusive lock to add the trigger back. Autonomous procedures AUTONOMOUS is a new stored procedure attribute that makes it easier to seamlessly add stored procedure calls into an existing application. Normally, COMMIT (and ROLLBACK) statements performed by a stored procedure will commit database changes made by the stored procedure as well as any outstanding database changes made by the stored procedure invoker. If a stored procedure didn’t commit its database changes, any Rollback statement issued by the invoker can undo the changes made by the procedure. Creating an autonomous stored procedure enables the data changes to be committed independently of the program that invokes the stored procedure. In the autonomous update_agency procedure shown here, the UPDATE and INSERT statements performed by the procedure will automatically be committed by DB2 as long as no errors are encountered. Any commit or rollback operations performed by invokers of the update_agency procedure will not affect the update and insert operations done by this autonomous procedure. Changes made by an autonomous stored procedure are completely independent of the changes made by the invoking application.
- 14. Additional App Development Enhancements The timestamp precision support is an enhancement that can be used to simplify your table definitions and potentially reduce storage usage. On previous releases, all timestamp values were stored with a precision down to the microsecond level (e.g., ‘2014-04-20 15:12:11.129897’). Some applications may not require this sub-second precision, so essentially the extra 6 digits of precision was wasting 3 bytes of storage in every row. The 7.2 release provides easy control of the timestamp precision value as demonstrated with the CREATE TABLE statement. As you can see in this example, not only can timestamp sub-second precision be eliminated it can also be increased up to 12 digits to more accurately capture timestamp values on today’s faster servers. The new ON VIOLATION clause allows applications to avoid run-time errors. Instead of an application failing when an insert or update operation causes a check constraint error, the new clause can direct DB2 to take a different action. As you can see in this example, DB2 will automatically use the column default value for insert operations that violate a check constraint and DB2 will automatically restore a row back to its original value when an update operation causes a check constraint violation. The ability to specify expressions on PREPARE and EXECUTE statement can reduce the number of statements that you have to code by eliminating the need to first store the result of an expression into a variable. Now, the expression can be embedded directly within your dynamic SQL request. Several advanced query capabilities were delivered as part of IBM i 7.1 technology refreshes. These new features enable SQL statements to invoke web services, recursively process relationships such as bill of materials, and perform advanced XML processing.
- 15. Built‐In Global Variables The IBM i 7.1 release delivered SQL Global Variable support. Global variables enabled user applications to easily pass and share values across SQL statements. The DB2 7.2 support has built on top of that support and provided a set of built-in global variables. Only the DB2 engine can assign values to a built-in global variable, but your applications can retrieve the values to learn details about the context and environment that your application is running in. For example, interactive applications could determine the IP address of the client that is running the application to make a decision on whether or not sensitive data should be shared with that client.
- 16. SQL Development Tools It’s pretty obvious that with the DB2 for i 7.2 enhancements discussed so far, the SQL capabilities of DB2 for i are growing with each release and technology refresh. To best leverage these SQL advancements, you need to be using development tools that make it easier for you to code and maintain SQL-centric applications. IBM Rational Developer for i (RDi) provides a graphical development that accelerates the development of applications that contain embedded SQL such as RPG and COBOL programs with its syntax highlighting and template capabilities. A free trial-version can be downloaded. IBM Data Studio is a no-charge download tool that shares much of SQL development with RDi, but it’s primary purpose is accelerating the development of SQL procedures and user-defined functions. Reporting is a key component of almost all applications, so you’ll not want to overlook the capabilities of IBM DB2 Web Query for i. DB2 Web Query shields report authors and end users from the complexities of SQL while also a providing a rich set of output format (PDF, HTML, and more) through its browser-based interface. As you can see from the image, this includes mobile device support.
- 18. Separation of Duties Several high-profile data breaches have many companies pressing their IT organizations to limit and control access to sensitive data. As a result, there’s been a greater emphasis on ensuring that security personnel don’t have too much power. A separation of duties approach is often implemented to prevent a security administrator from having the ability to both control data access and perform data access. IBM has delivered a new DB2 security administration function usage, QIBM_DB_SECADM, so that a security administrator can be limited to just the duty of controlling data access. This control is implemented by using the CHGFCNUSG (Change Function Usage) command. Once this command has been executed, the specified user profile (SECUSR) will be able to grant read access to DB2 tables to other users, but will not be able to read the content of any DB2 table. A DB2 security administrator can only grant data access to others, not themselves.
- 19. The Business Problem This separation of duties enhancement helps with controlling access at the object level, but isn’t helpful for users wanting to grow data access at the row and column level. In prior releases, IBM i really only provided controls for an all or nothing approach - either a user had no access to the values in a row/column or had access to all of the values in a row/column. Some tried implementing these more granular controls with SQL views and application logic, but found these user-defined solutions to be costly to maintain and easy to bypass. Those limitations are a thing of the past with the new DB2 Row and Column Access Control (RCAC) support.
- 20. What is RCAC? RCAC is an additional layer of security that complements table-level authorizations that are already in place in your database. RCAC does have the ability to protect at the table row level, table column level, or both, providing a masking of result sets to the users based on the required level of data protection. This protection is done via row permission and column mask rules. These rules are checked every time a row is accessed – regardless if the row is accessed with SQL or non-SQL interfaces The image on the slide simply shows at a high-level, a column with sensitive data (social security number) whose value is masked out (it is in green) and that a number of rows are not returned (in red) based on row permission and column masks that have been defined. Row permissions enable you to define a rule that will determine whether a user is authorized to access a row within a table. This rule is checked every time a row is accessed. A row permission rule is only applied after the table-level authorization has been first verified. Column mask rules are applied after a row has been rule eligible to access. A column mask determines if the user is authorized to see the actual value or if a masked version of the data (*****123) should be returned instead. In order to use the DB2 for i RCAC support, the no-charge IBM Advanced Data Security feature must be installed on development and production systems.
- 21. Why use RCAC? In any organization, data must be protected and only users who need to see certain data should be able to see this data. Depending on the job role, different data values should not be visible. You could use SQL Views to prevent access to sensitive columns in a table of course, but this adds complexity and exposes to the users that there may be data that is not accessible. It also adds maintenance complexity. Application logic could also be used, but those security controls are worthless when DB2 objects are directly accessed. Speaking of direct access, security administrators or users with *ALLOBJ special authority are able to access all of the data in a table. As a result, you really need something like the DB2 RCAC support for ease of use and ease of implementation in controlling data access across all interfaces and users.
- 22. Scenario: HealthCare Industry Let’s use this sample scenario based on the healthcare industry as we moved forward in this presentation to better understand RCAC support. Providing data to a hospital for instance, can in reality have this data be provided to a number of other organizations like the insurance company, research and so on. Each of these companies have their own employees and there are government regulations in place dictating who can see what data or parts of data. As a result security policies must be in place to ensure the rules are being met. Across the scenario there will be different groups of individuals access the database and there must be security in place to ensure each group or individual only sees the data they are allowed to see.
- 23. Scenario: Create Permission In this healthcare scenario, there are four groups of individuals that have different data access requirements. These distinct requirements are highlighted by the 3 green numbers on the chart. All of the individuals have read and update authority to the table, but they need to be limited to a subset of the data in the table. The next page will show the detailed implementation of these data access requirements.
- 24. Scenario: Create Permission Here is permission definition for the three rules described on the previous page. Notice that in this example all of data access rules were able to be implemented with a single row permission. This permission example demonstrates that column values (userid and pcp_id) and function calls can be utilized in the coding of a row permission. On each rule, the permission validates if the user belongs to a specified group profile. The VERIFY_GROUP_FOR_USER function is a built-in system function that can be used to determine if the current user (ie, SESSION_USER) belongs to an IBM i group profile or matches a user profile value. The VERIFY_GROUP_FOR_USER function returns a value of 1 if the input user profile matches the specified group or user profile values. If the user belongs to the patient group and the row contains their patient data, they will have access to the row. For a physician, the next check compares the data to allow the physician to see only see data for their own patients. The third condition allows users that belong to the membership, accounting or research group profiles to access any of the rows in the table. Once the row permission is created, enforcement does not take place until the permission is activated with an ALTER TABLE statement.
- 25. Scenario: Update Table with Permissions With the row permission now activated, we will allow Dr. Lee runs an application that updates data in the patient table. The UPDATE statement tries to change data for a patient named Sam. Sam is a patient of Dr. Lee, so the row permission enables Dr. Lee to access Sam’s data. As a result, this UPDATE statement completes successfully since Sam is a patient of Dr. Lee.
- 26. Scenario: Update Table with Permissions The application that Dr. Lee is using tries to update data for a different patient – Doug. This data access request is in conflict with the data access requirements defined earlier. The row permission causes this UPDATE statement to fail. However, that a security error is not returned. Instead the application and Dr. Lee are informed that the UPDATE statement could not find any rows containing data for a patient named Doug. This behavior is consistent with Dr. Lee being able to see data only for his patients. The RCAC support provides no indication that there is a patient named Doug – it simply limits Dr. Lee’s access to his patient data. This is important for ensuring data is only visible to those with appropriate access rights.
- 27. Scenario: Select from Table with Permissions According to the row permission defined earlier, Dr. Lee can only see the data of his own patients. That’s exactly the behavior of this SELECT statement executed by Dr. Lee – the result set contains 3 rows that represent his set of patients. The doctor has no knowledge or visibility of any patient that is not his own. This simple example is important for a multi-tenancy environment where each organization would only have knowledge of their data without even a hint that other data may be in the tables or database.
- 28. Scenario: Select from Table with Permissions The same SELECT statement is now run by different users (John, Jane, and Tom) and returns data for all patients. These three individuals all belong to user group profiles – Accounting, Research, and Membership - that have authorization to access all of the rows.
- 29. Scenario: Create Column Mask Moving on, let’s discuss how you would implement the column access control. Remember that RCAC provides both column access and row access controls. Column access control is implemented in the form of a mask, or lack thereof, on the data. In this scenario, only the patient is allowed to see the full patient identifier(pid) value. All other users should only have access to the last three digits of the patient identifier. The column mask definition decides which value to return for the pid column by using a case expression to determine if the user accessing the data is a patient or not. Notice that the column mask doesn’t have to check which patient’s data is being accessed due to the fact that behavior is controlled by the row permission. The mask simply checks if the current user belongs to the patient group profile or not. When the user is not part of the patient group profile, a mask value of ‘XXX XXX’ is concatenated with the last 3 digits of the pid column returned by the substring function.
- 30. Scenario: Select from Table with Mask Let us now see how this column mask affects Dr. Lee’s data access. The same SELECT statement from previous examples is run by Dr. Lee. In this example, both row and column access control rules are applied. This result set only contains the rows for Dr. Lee’s three patients. In addition, the values retrieved for the pid column are masked.
- 31. Scenario: Select from Table with Mask In this last example, a patient named Bob runs the same SELECT statement. Because Bob is a patient, the result set only contains a single row. However, the full patient identifier value is displayed instead of a masked value.
- 32. RCAC Considerations Only those users that have been designated a DB2 Security Administrator with the QIBM_DB_SECADM function usage are able to add row permissions and column masks to a table (or physical file). Creating a row permission or column mask doesn’t create an IBM i operating system object. Instead, the rules are stored in the table object. The DSPOBJAUT command can be used to see if any row or column access controls are active on a table. However, the definition of the controls can only be accessed by using system APIs, retrieving data from DB2 catalog views, or using one of the Navigator clients. Because the access controls are stored as part of the DB2 table object, the controls are automatically transferred to any SQL views that reference a table with active RCAC rules. If RCAC rules are added to an existing table that has triggers or user-defined functions that reference the table, then the triggers and user-defined functions must be altered to use the SECURED option. Without the SECURED option, triggers and user-defined functions will not work against an RCAC table. Native query interfaces such as OPNQRYF and RUNQRY may return slightly different results when accessing a table with active RCAC controls. These slight behavioral differences will be discussed more in the Performance section of this presentation. There are some interfaces and options that will not work at all when referencing a table with RCAC controls. Review the list of unsupported interfaces to determine if this is an issue with your environment at all.
- 33. Additional security enhancements The new TRANSFER OWNERSHIP statement simplifies administration of SQL-created databases by allowing the ownership of DB2 objects to be changed with SQL. In prior releases, the CHGOBJOWN (Change Object Owner) system command would have to be used or the object would need to be recreated. Your SQL GRANT and REVOKE statements can also be easier to understand with the ability to specify the new USER and GROUP keywords on the request. Prior releases allow both an IBM i user profile or group profile to be specified on the GRANT and REVOKE statements, but there was no indicator on what type of profile was being referenced. The new keywords resolve that ambiguity. The final security enhancement is the addition of a new special register named CURRENT_USER. The CURRENT_USER special register behaves exactly the same as the existing SESSION_USER special register with one exception. That different behavior occurs when a program has been executed that adopts authority of a different user profile. In this case, the CURRENT_USER special register will return the value of the adopted authority user profile.
- 35. Manageability Enhancements As you can see from this list, the manageability improvements for DB2 for i range from enhancements to the graphical System i Navigator interface to the new DB2 for i services via new catalog objects to a new TRUNCATE statement. Some of these enhancements will be explored in further detail.
- 36. Graphical Management – System i Navigator The System i Navigator toolset provides the primary interface for managing and administering DB2 for i databases. You can see from this list of enhancements that both the performance tuning and management capabilities of this interface have been bolstered. Notice that all of these new features are also available on the 7.1 release. One of the main reasons is that IBM did not deliver a 7.2 version of the System i Navigator client – instead all of the enhancements are being added to the 7.1 client. So you’ll just want to make sure that you have the latest version of the IBM i Access for Windows service pack installed on your client in order to have access to all of new features. From a performance analysis perspective, the SQL Plan Cache is becoming the primary tool for identifying SQL performance bottlenecks. This momentum started with the IBM i 7.1 release when the newer SQL Query Engine(SQE) finally had the ability to process all SQL statements. With this increased popularity, IBM has beefed up the Plan Cache properties and the analysis of advised indexes through the Plan Cache. On the management side of the list, Run SQL Script users will also benefit from the new capability to save result sets returned from a stored procedure call. This capability is quite useful when testing and debugging stored procedures. Speaking of debug, you also can now step through your SQL procedures and functions in the graphical debugger with a single click - instead of clicking multiple times to advance past a single SQL statement.
- 37. Plan Cache – Enhanced Metrics & Controls From this image, you can see the SQL Plan Cache Properties interface now includes a ton more statistics and metrics – especially when you compare this with the properties returned by the original Plan Cache tool delivered in the IBM i V5R4 release. These additional metrics make it quicker for you to determine how your SQL workloads are benefitting from the plans automatically being cached by the DB2 engine to identify potential improvement areas. Because no two SQL workloads are identical, DB2 now allows you to control new settings such as the hit ratio and maximum cache size to customize the SQL Plan Cache to best match the requirements of the SQL workload running on your system. While most customers experience great SQL performance using the default configuration settings (values of *AUTO or *DEFAULT )for these Plan Cache settings, there have been some unique workloads that require a different Plan Cache behavior. The best resource for understanding when and how to change these configuration values is gained by attending the DB2 for i SQL Performance Workshop.
- 38. Generate SQL – Enhanced DDS Conversion You can see from the Generate SQL interface that this utility has been enhanced with to better support conversion of DDS created databases over to SQL. At the heart of the improvements is the ability to now also generate SQL indexes to match the functionality of the key definitions often embedded within logical files and physical files. More details on this enhancement can be found here. A GENERATE_SQL stored procedure is also now available so that the utility can also be invoked programmatically in addition to a user being able to interactively generate SQL statements for DB2 objects.
- 39. Health Center – System Limits The breadth of the Health Center has been expanded to track and monitor the status of various IBM i operating system limits in addition to DB2 limits. In this example, the new System Limits tab shows how close the system has come to journal-related limits, the maximum number of object descriptions in a library, and the maximum number of spool files. Additional details on the System Limits support.
- 40. Performance Data Investigator (PDI) PDI is a performance toolset that is not well-known by IBM i clients. This browser-based tool can be used for assessing and analyzing IBM i performance issues. Recent enhancements include new DB2 reports and metrics to make it easier to use this tooling to identify database related performance bottlenecks. PDI is access using the IBM Navigator for i browser-based client.
- 41. Browser client The discussion of PDI’s browser-based interface may have you wondering if IBM also provides the ability to manage DB2 through the same interface. The IBM Navigator for i browser client does provide interfaces for managing DB2 for i databases similar to the System i Navigator client. So, the answer is yes with a few caveats. However, notice in the “Interface Differences” section that the Visual Explain and Run SQL Script functions are not yet available in the browser interface. Depending on the administrative tasks that you’re trying to perform that may or may not be a big deal. If you’ve never tried out the browser interfaces for DB2, just use the following launch URL along with the host name of your IBM i system to give them a trial run. https://<ibm i host name>:2005/ibm/console/logon.jsp
- 42. SQL Scripting with Dynamic Compound Statement The new SQL dynamic compound statement support allows IBM i developers to develop robust SQL scripts. The ability to execute a standalone compound statement gives developers access to the full procedural capabilities of SQL which includes error handling and conditional constructs. Without procedural SQL support, SQL scripts to create or install databases were very limited in terms of their robustness and flexibility. A dynamic compound statement is coded by simply using the BEGIN and END clauses around your SQL script. The compound statement in this example demonstrates the usage of a continue handler to deal with the DROP TABLE statement possibly failing due to the orders table not existing on the system where the SQL script is running. This compound statement is also passed input values through the usage of the Create_Var global variable. SQL global variables make it easy to customize the behavior of your SQL scripts with input values. Global variables can also be used to passed feedback from the compound statement.
- 43. SQL Scripting with Dynamic Compound Statement Many IBM i development shops use CL programs to create and install their databases. The dynamic compound statement support can be leveraged in this type of programming environment as well by using the RUNSQL or RUNSQLSTM CL commands to execute the compound statement. In this example, the RUNSQL CL command is used to execute the dynamic compound statement on the prior page. Notice that the value of the Create_Var global variable is assigned based on the value of the CRTMOD input parameter passed to the CL program.
- 44. Additional Management Enhancements A new SQL TRUNCATE statement now allows you to quickly delete rows from a DB2 table. While this is similar to the function provided by the CLRPFM (Clear Physical File Member) command, the TRUNCATE statement also includes advanced controls such as the ability to control the behavior of identity columns and storage reuse. Speaking of tables with an identity column, the RESTART_IDENTITY system utility makes it easier to preserve the next identity value when making copies of tables with commands such as the CPYF command. After your copy has been made, just give the utility the name of the source and target tables and DB2 will automatically reset the target table to have the same next identity value as the source table. The DB2 for i Catalog has been expanded to include a set of general system views and functions known as DB2 for i Services that make it quite simple to access operating system metadata and metrics with SQL.
- 45. DB2 for i Services Examples This simplicity is demonstrated with these examples that query a couple of the new catalog service objects. The first query returns a list of the user profiles that have been authorized to the new QIBM_DB_SECADM function usage id. While the second query returns a list of the active jobs that are consuming the most temporary storage on the system – the SYSTMPSTG catalog view leverages the temporary storage management enhancements delivered in the IBM i 7.2 release.
- 46. DB2 for i Services A complete listing of all the services can be found on the referenced IBM i developerWorks page. On this page, you see a listing of the more interesting service objects that can you leverage for analyzing performance and security settings as well as developing reports to return your operating system configuration.
- 47. Availability & Recovery Enhancements The remote journal function offers improved security with support for SSL. Usage of VPNs was the only way to secure remote journal traffic in prior releases. Deferred processing for the restore of journal objects simplifies your database recovery process by eliminating the requirement to correctly order the objects being restored. The IBM i operating system also provides an enhanced DISPLAY_JOURNAL table function to make it simpler to analyze and retrieve the journal entries. This function can be useful for both data and audit journals.
- 48. Availability & Recovery Enhancements As you can in this figure, the Navigator client offers a graphical interface for interactively viewing journal entries. This supports complements the programmatic interface provided by the DISPLAY_JOURNAL table function.
- 50. Performance & Scalability Enhancements The scalability of SQL workloads will benefit from the SQL Query Engine’s (SQE) enhanced I/O costing algorithms which will allow it to better utilize advanced I/O devices such as SSDs (solid state drives). The IN predicate processing advancements should also provide a boost to more complex queries. SQE also automates some performance tuning by automatically adjusting the size of the SQL plan cache and remembering plan cache size adjustments across IPL. Larger databases will benefit from the DB2 7.2 enhancements that increase the maximum size of an index object to 1.7 Terabytes, strengthen reuse deleted records processing with VLDB awareness, and enhance storage utilization for variable-length and LOB columns.
- 51. SQE Native Query Support With the IBM i 7.2 release, SQE now has the ability to process IBM i native query requests such as the OPNQRYF and RUNQRY commands. While this enhancement can be viewed as beneficial, you should carefully consider if you want to use this default behavior. Legacy queries that have been running without any issues for many years and over many IBM i releases will now be processed by a completely different query engine. As a result, the run time behavior and results returned can be different for OPNQRYF and Query/400 requests. This chart lists some of the query output differences that can occur when SQE is allowed to process the native query requests. Based on the potential impacts on run time performance and query result sets, IBM recommends that you perform extensive functional testing and performance benchmarking of your applications and all reports. This activity will help you identify if additional tuning steps such as creating new indexes is required, and more importantly if any of your queries are returning different results. If you want to avoid the risk of potential impacts, you can set the QAQQINI parameter, SQE_NATIVE_QUERY, to a value of *NO. With a value of *NO, DB2 will limit SQE usage to SQL-based interfaces, making the behavior equivalent to the IBM i 6.1 and 7.1 releases. Strategically, it is a better return on investment to spend time converting your OPNQRYF and Query/400 reports to SQL. This will provide you access to the superior functionality and advanced features offered by standard and portable SQL.
- 52. In‐Memory Database Enablement DB2’s In-Memory database support is now SQL-friendly with the new KEEP IN MEMORY clause that can be specified on SQL table and index definitions. In the prior release, the CHGPF and CHGLF commands had to be used to exploit the in-memory database capabilities for SQL objects. That’s no longer the case with the DB2 7.2 release as this CREATE INDEX demonstrates: CREATE INDEX important_index ON important_table(columnX, columnY) KEEP IN MEMORY YES It’s important to note that the in-memory processing is only performed for SQL interfaces.
- 53. Summary You should now see that the DB2 for i 7.2 release provides enhancements that should simplify your everyday activities regardless of your role – developer, database engineer, system administrator, or security officer. IBM continues to deliver enhancements that make DB2 for i database easy to manage while at the same time meeting the security and scalability requirements that your business dictates. Spend a few moments reviewing the Web sites provided in the Resources section of this course. These sites will help you gain an even deeper understanding of the value you can derive by working with DB2 for i 7.2 and previous releases.