In this article I will discuss what commitment control is, why you may want to use it, and the basic requirements for commitment control. In subsequent articles we will look more closely at some of the considerations for using commitment control effectively: how commitment control works; different ways in which it can be implemented; and how it works in ILE.

Throughout these articles I will be using the SQL terminology of schema, table, row, and index as opposed to library, physical file, record, and logical file. However, be aware that commitment control is applicable to both SQL-defined tables and DDS-defined

Part 1 of this series focused on some of the stellar query enhancements IBM gave its DB2 for i developer community. It’s hard to believe the 20-plus-year-old AS/400 system (now called IBM i) can continue to look so young given its great strengths in database and other areas. But for now, I want to focus on specialized query enhancements called grouping sets and super groups.

The ability to work with grouping sets and super groups in a query is an overdue feature, in my opinion (which incidentally has long been available with other versions of DB2 and other database servers).

Compared to other platforms, the i5/OS operating system is one of the more secure systems available today. However, that doesn’t mean there aren’t any security holes. This week, let’s look at some common user profile security problems that iSeries, System i, and Power i shops encounter and talk about how you can counter these issues.

Auditing Your User Profiles

To truly troubleshoot the issues I’m discussing here, you’ll need to create a user profile information file (UPIF). It’s easy to create a UPIF and once you have it, you can query individual user profiles to determine which profiles have which