planetDB2 logo

Planet DB2 is an aggregator of blogs about the IBM DB2 database server. We combine and republish posts by bloggers around the world. Email us to have your blog included.


December 18, 2017

Craig Mullins

The Db2 12 for z/OS Blog Series - Part 20: Fast Insert: An Alternative INSERT Algorithm

Db2 12 offers many performance improvements that can help you to speed up your applications. The Fast Insert algorithm, also called Insert Algorithm 2, is one such improvement, but you have to understand what it is and when it can be helpful. The general idea behind this alternative Insert algorithm is to improve performance of Insert-intensive workloads for unclustered data. This is a common...

(Read more)

December 15, 2017

Adam Gartenberg

Connections Customizer now Generally Available

An important part of the "Pink" vision for the future of IBM Connections is the ability to extend and customize the environment. We took a big step forward in that vision with the general...

(Read more)

December 14, 2017

Kim May

First Half 2018 Classes Posted at www/

The Fillmore Group 1H 2018 Class Schedule As an IBM Business Partner that truly believes that proper training is one of the most critical factors influencing the successful deployment and use of...

(Read more)
Modern SQL

Modern SQL: Three-Valued Logic (3VL) — Purpose, Benefits and Special Cases

The Three-Valued Logic of SQL

SQL uses a three-valued logic: besides true and false, the result of logical expressions can also be unknown. SQL’s three valued logic is a consequence of supporting null to mark absent data. If a null value affects the result of a logical expression, the result is neither true nor false but unknown.

The three-valued logic is an integral part of Core SQL and it is followed by pretty much every SQL database.

Comparisons to null

The SQL null value basically means “could be anything”. It is therefore impossible to tell whether a comparison to null is true or false. That’s where the third logical value, unknown, comes in. Unknown means “true or false, depending on the null values”.

The result of each of the following comparisons is therefore unknown:0

NULL = 1
NULL <> 1
NULL > 1

Nothing equals null. Not even null equals null because each null could be different.


For comparisons every null is a different null. This is different in group by, partition by and related operations.

That’s why SQL has the is null predicate to test whether a value is null or not and the is not distinct from predicate to compare two values while treating two null values as the same.

Logical Operations Involving Unknown

In logical connections (and, or), unknown behaves like the null value in comparisons: The result is unknown if it depends on an operand that is unknown. In contrast to comparisons, this principle leads to cases in which the result of a logical connection is not unknown even though one operand is unknown. The reason is that the result of a logical connection is only unknown if it actually depends on an operand that is unknown.

Consider the following example:

(NULL = 1) OR (1 = 1)

Although the comparison to null makes the first operand of the or operation unknown, the total result is still true because or operations are true as soon as any operand is true.

Another way to look at it is to mentally replace each null with a call to a random() function. If the overall result of the expression is inevitably the same, no matter which value random() returns, the result obviously does not depend on the null value and it is therefore not unknown.

In the example above you can assume the values 0 and 1 instead of null to make the result of the first operand false and true respectively. But the result of the complete expression is true in both cases—it does not depend on the value you assume for null.


The logical value unknown indicates that a result actually depends on a null value.

A similar case applies to the and operator: and connections are false as soon as any operand is false. The result of the following expression is therefore false:

(NULL = 1) AND (0 = 1)

In all other cases, any unknown operand for not, and, and or causes the logical operation to return unknown.1

General Rule: where, having, when, etc.

The where, having, and when clauses (e.g. in case expressions) require true conditions.2 It is not enough that a condition is not false.

The result of the following query is therefore always the empty set:

  FROM t

The result of the equals comparison to null is always unknown. The where clause thus rejects all rows.

Use the is null predicate to search for null values:


Odd Consequence: P or not P is not always true

As the name “three-valued logic” suggests, there are three values to consider in logical expressions. At first sight the following where clause looks like a tautology—i.e. a condition that is always true. Nonetheless, it behaves entirely differently as it considers only two out of the three possible values—namely that the condition col = NULL is true or false.

  FROM t
 WHERE      col = NULL
    OR NOT (col = NULL)

(1) The result of the comparison col = null is unknown in both cases; (2) not(unknown) is also unknown; (3) or only evaluates as true if one operand is true. Consequently, the condition is always unknown so that the where clause rejects all rows. This is clearly quite the opposite of what two-valued logic would suggest.3

Odd Consequence: not in (null, …) is never true

Consider this example:


To understand this example, read null as “could be anything” or random() if you prefer. Then try to find two values for null that make the expression true and false respectively. Let’s take 0 and 1. For 0, the expressions becomes 1 NOT IN (0), which is true. For 1, the expression becomes 1 NOT IN (1), which is clearly false. The result of the original expression is therefore unknown, because it changes if null is replaced by different values.

If we extend this example we will quickly see that the result of not in predicates that contain a null value is never true:


This expression is again unknown because substituting different values for null (e.g. 0 and 1) still influences the result. It is nevertheless easy to show that not in predicates that contain a null value can be false:


No matter which value you substitute for the null (0, 1 or any other value) the result is always false.4


Don’t allow null in not in lists.

When using a subquery, consider using not exists instead of not in5 or add a where condition to the subquery that removes possible null values.

Exception: Check Constraints

Check constraints follow the reverse logic: they reject false, rather than accepting true as the other clauses do.6 Consequently, check constraints accept true and unknown.

In the following example, the column a or b can have a value greater 10 if the other column is null:

    a NUMERIC CHECK (a >= 0),
    b NUMERIC CHECK (b >= 0),
    CHECK ( a + b <= 10 )

Truth Value Tests: is [not] (true|false|unknown)

Similar to is null, the SQL standard defines an optional feature to directly test for all three truth values:7

is [not] (true|false|unknown)

Note that this is test never returns unknown (very much like is [not] null).8

Compatibility below describes which databases support this feature.


Use (<expr>) is not false instead of (<expr>) or (<expr>) is null. See also Binary Decisions Based on Three-Valued Results below.

Boolean Data Type: Literals true, false and unknown

The barely supported optional feature T031, “BOOLEAN data type”, introduces the keywords true, false and unknown outside of the is predicate.

Note that the truth value unknown is indistinguishable from the null for the Boolean type.9 Otherwise, the Boolean type would have four logical values.

The difference between the literals null and unknown is that unknown is of type Boolean while null can take any type. Putting a not null constraint on a column of the SQL type Boolean makes it a classical two-valued Boolean.

Binary Decisions Based on Three-Valued Results

The three-valued logic of SQL postpones a binary decision if a logical expression cannot be said to be unconditionally true or false. However, in the end there is always a truly binary decision, such as taking or rejecting a row due to a where clause.10

As explained above, the SQL standard generally treats unknown like false when it eventually has to make a binary decision (exception: check constraints). Think of it like an implied is true test on every where, having, and so on.

Treating unknown like false is not always the right choice. If you need another behavior, just use an explicit is [not] (true|false|unknown) test.

Consider the following example that uses nullif to prevent a potential division by zero error. Consequently, the where condition becomes unknown for rows where d is zero (0) and those rows are rejected by the where clause.

  FROM t
 WHERE n/NULLIF(d,0) > 1

If you need to return the rows with d = 0 as well, you can add OR d = 0 to the where clause. Of course this is a correct solution, but it requires an understanding of the condition. A more generic approach is to repeat the entire null-able expression in order to explicitly include the null case: OR (n/NULLIF(d,0)) IS NULL. Still, that is not exactly elegant.

The idiomatic way to reduce a three-valued result to a two-valued one is the truth value test is [not] (true|false|unknown):


This accepts both results—true and unknown—and is logically equivalent to the solutions that use an or connection. The benefit is that it does not require any repetition or semantic understanding of the condition.


Put the condition in parenthesis to avoid ambiguity:


The is not false predicate belongs to the optional feature F571, “Truth value tests”, which is still not generally supported. It is nevertheless possible to implement the same logic, without repeating parts of the expression, in practically all SQL databases with a case expression:

            THEN 0
            ELSE 1
        END = 1

This expression explicitly tests for the false case (when not (…)) and uses the else clause to catch the two other cases (true and unknown). This allows for the required mapping without repeating any part of the condition. The numeric literals were arbitrarily chosen to represent “false” (0) and “true or unknown” (1). The concluding comparison (= 1) is always true or false because neither operand can ever become null.

The workaround with case can map unknown to either true or false. This covers four out of the six possible cases: is [not] (true|false). The two remaining cases, is unknown and is not unknown, cannot be implemented using case without repeating some parts of the logical expression.

To emulate the is [not] unknown test, you can exploit the fact that unknown is the same as null for Boolean values. In principle, it is possible to use is [not] null to test for unknown. In practice, this is hardly useful because most databases that don’t support is [not] unknown don’t support the Boolean type either.

That means that you must test the operands of the comparison for null and combine the result logically.

The following example demonstrates this:

(<expr1> <op> <expr2>) IS UNKNOWN

This is logically equivalent to:

   <expr1> IS NULL
OR <expr2> IS NULL

For an is not unknown test you have to use is not null tests and combine them with a logical and operation.11


Three-valued logic has been in the SQL standard from the beginning. It is an integral and widely supported aspect of SQL.

SQL:1999 added two related optional features:

  • F571, “Truth value tests”: extends the is operator for all three logical values.

  • T031, “BOOLEAN data type”: defines the Boolean data type, the aggregate functions every, any, and some, as well as the literals true, false, and unknown (other than following is [not]).

Availability of Features Coping With Three-Valued Logic

The Three-Valued Logic of SQL” by Markus Winand was originally published at modern SQL.


December 13, 2017

Triton Consulting

Have you got Christmas covered?

With Christmas just around the corner now is a good time to consider additional support over the holiday period. Perhaps you have a small in-house team or are struggling to find DB2 resources. Providing adequate cover for your DB2 databases … Continue reading →

(Read more)

December 12, 2017

Henrik Loeser

News on IBM Cloud and Db2 - December 2017 Edition

Another month and a lot of news In the middle of November I reported about significant changes to Bluemix and IBM's cloud offerings. A month has passed and I want to give you an update to some news...

(Read more)


The Evolution of Compression: Db2 11

This is my fourth installment in a series detailing the history of Db2 compression. As is the case with all previous releases, the Db2 engine takes advantage of the z System hardware platform in Db2 Version 11 for z/OS. With Db2 11 and zEC12 hardware, compression overhead was reduced by as much as 15 percent.

December 11, 2017

Jack Vamvas

How to check DB2 LUW load status

Question: How can I check load status in DB2 LUW?

Answer: Checking the DB2 LUW load status is achieved by using the load query command. The best way to explain is by demonstrating with a simple example.

The DB2 LUW command is used to load data into a DB2 LUW table. The data can be stored in many different forms – including named pipe and tape

Starting the load process


connect to mydb; 
create table table2 like table1; 
load from somedata.del of del insert into table2; 

While the load process is in flight , create another connection and view the progress

connect to mydb; 
load query table table2; 
connect reset;

 Read More on topics related to How to check DB2 LUW load status 

db2move to copy data between databases


December 08, 2017

DB2Night Replays

The DB2Night Show #199: Awaken your Data with RESTful Access to Db2!

Follow @upintheairyyz Special Guest: George Baklarz, Program Director, IBM Canada Awaken your Data with RESTful Access to Db2! OData! 100% of our audience learned something! The new IBM Data Server Gateway for OData is a standards-based way for customers to leverage Db2 in modern Cloud and Mobile application development environments without requiring database drivers on the client. This show described what OData is, how it works with...

(Read more)

December 06, 2017

Modern SQL

Modern SQL: IS DISTINCT FROM — A comparison operator that treats two NULL values as the same

NULL-Aware Comparison: is [not] distinct from

In SQL null is not equal (=) to anything—not even to another null. According to the three-valued logic of SQL, the result of null = null is not true but unknown. SQL has the is [not] null predicate to test if a particular value is null.

With is [not] distinct from SQL also provides a comparison operator that treats two null values as the same.

<expression> IS NOT DISTINCT FROM <expression>

Note that you have to use the negated form with not to arrive at similar logic to the equals (=) operator.

The following truth table highlights the differences between the equals sign (=) and is not distinct from.


The result with equals (=) is unknown if one operator is null. The is not distinct from comparison is true if both values are null or false if only one is null.

Conforming Alternatives


Although there are standard alternatives to is not distinct from, using a proprietary alternative is often the better choice.

Due to SQL’s three-valued logic, a fully equivalent substitute for A is not distinct from B that works in all SQL databases is surprisingly complex:

CASE WHEN (a = b) or (a IS NULL AND b IS NULL)
     THEN 0
     ELSE 1
 END = 0

The result of the expression in the when clause is true if both arguments are equal or both are null. If only one argument is null the result is unknown, not false. This is often not a problem because SQL generally treats unknown like false when making binary decisions such as accepting or rejecting a row for a where clause.

To get the fully equivalent functionality of is not distinct from—i.e. either true or false but never unknown—the case expression reduces the three-valued result into a two a two-valued one. In some databases is not false can be used instead of the case expression. This technique is explained in Binary Decisions Based on Three-Valued Results.

Another option is to use set operators, which use distinct comparisons internally. The following snippet uses intersect to determine a common subset. The two compared sets are just one value each (one row with one column). If it is twice the same value the common subset will be that value. Otherwise the common subset is empty. This logic can be easily tested in the where clause with an exists predicate:0

        VALUES (B)

This has the advantage that it does not repeat any expressions. Unfortunately, it doesn't work on all databases due to the use of the values clause. A select from a one-row dummy table can be used to get a conforming and widely supported solution.


The is [not] distinct from predicate was introduced in two steps: SQL:1999 added T151, “DISTINCT predicate”. The optional negation with not was added by SQL:2003 as feature T152, “DISTINCT predicate with negation”.

Availability of IS [NOT] DISTINCT FROM

Proprietary Alternatives

Most database that do not offer is not distinct from offer a proprietary alternative that is more convenient than the conforming alternative described above. The following proprietary features are fully compatible—i.e. they have a two-valued result and never return unknown.

Proprietary Alternatives for IS [NOT] DISTINCT FROM

Exists, select without from, intersect

The standard solution using exists, values, and intersect can easily be modified to work on more databases by using select without from instead of the values clause:

        SELECT c2

decode — Db2, Oracle, H2

Db2, Oracle database, and H2 have the proprietary function decode that happens to use is not distinct from semantics internally.1 The following example has the same effect as A is not distinct from B:

DECODE(A, B, 0, 1) = 0

is — SQLite, H2

The is operator of SQLite (documentation) and H2 (documentation) is able to compare two expressions (not just is [not] null), and it has the same semantics as is not distinct from.

<=> — MySQL, MariaDB

MySQL offers the proprietary <=> comparison operator that works like is not distinct from.2


SQL Server’s deprecated ANSI_NULLS setting makes some equals comparison (=) act as though it was a is not distinct from comparison.


ANSI_NULLS OFF is deprecated: it’s use may cause errors in future versions of SQL Server.

Also note that it does not affect all equals signs, but only those where one side of the comparison is a variable or the null literal. It does not affect general <expression> = <expression> comparisons.

NULL-Aware Comparison: is [not] distinct from” by Markus Winand was originally published at modern SQL.


December 05, 2017


The Evolution of Compression: Db2 10

My backgrounder on compression continues with Db2 for z/OS Version 10. This release brought compression support to SMF trace data and provided an availability option to activate data compression without placing the table space in REORG pending.

December 03, 2017

DB2Night Replays

The DB2Night Show #Z82: The Db2 12 Catalog -- What happened since Db2 11

Presented by: Steen Rasmussen CA technologies "The DB2Night Show #Z82: The Db2 12 Catalog -- What happened since Db2 11" Replays available in WMV and M4V formats! 100% of our studio audience learned something!Steen described the Db2 12 catalog changes abd their role in support new and improved Db2 features. Watch the replay...

(Read more)

December 01, 2017

Henrik Loeser

IBM Cloud: Some fun with Python and Cloud Foundry Logging

IBM Cloud: Turn Log Data into Donut Last month, after receiving user questions, I blogged about how to decipher Cloud Foundry log entries. Today, I want to point you to a small Cloud Foundry Python...

(Read more)

November 28, 2017

Kim May

It’s Q4 and the Second Opinion Clinic is Open

It’s Q4 – and that means IBM software sellers are making their best deals.  As an IBM customer, you know the year end deals are the best available, right?  I hope so…but if you have...

(Read more)


The Evolution of Compression: Db2 9

Last week I discussed many of the data compression benefits delivered with Db2 8. That release included perhaps the most significant development in data compression in the past decade: since Version 8, Db2 has handled data compression using hardware, not software.
Modern SQL

Modern SQL: NULL — purpose, comparisons, NULL in expressions, mapping to/from NULL

NULL in SQL: Indicating the Absence of Data

“Every [SQL] data type includes a special value, called the null value,”0 “that is used to indicate the absence of any data value”.1

The null value does not indicate why a value is absent—it simply marks the places that do not have a data value. For example, the SQL language itself uses the null value for the absent values resulting from an outer join.2 Although exceptions exist3, it is not generally possible to tell why a value is null.

Users can use the null value for any reason they like. A very common use case is to allow optional attributes without introducing an extra table. Another important use case is error handling: Contrary to other programming languages, it is not an error to process null values in SQL. Null values just propagate through expressions without aborting execution.

Comparisons Involving null

Comparisons (<, >, =, …) to null are neither true nor false but instead return the third logical value of SQL: unknown. The following example removes all rows—even those where col is actually null—because the where clause treats unknown like false.

WHERE col = null


The SQL Server setting SET ANSI_NULLS OFF changes this behavior.

Testing for null: is [not] null

The SQL predicate is [not] null tests whether the result of an expression is null or not.

<expression> is null

This returns true if the value of expression is null, and false otherwise. The optional not negates the result.

Null-Aware Equals Comparison: is not distinct from

SQL uses two different concepts to tell if two values are the “same”: equals (=) and distinct. The difference is that equals (=) treats comparisons to null as indeterminate—that’s why col = null returns unknown. Distinct, on the other hand, treats null like any other value—i.e. two null values are not distinct from each other (they are indistinguishable) whereas a null value and a not null value are distinct values (not the same).

Originally, distinct was just a concept used internally in the SQL standard to define the behavior of group by, select distinct, count(distinct …) and the like. SQL:1999 and SQL:2003 introduced the is [not] distinct from predicate to make distinct comparisons available to SQL programmers.

<expr1> IS NOT DISTINCT FROM <expr2>

The is [not] distinct from predicate is an optional feature that is still not widely supported. See NULL-Aware Comparison: is [not] distinct from for alternatives.

Mapping to and from null

Sometimes it is required to turn a particular value into null or vice versa. The case expression has two shortcuts for the most common cases.

Coalesce — Map null to Another Value

SQL’s coalesce turns a null value into another value.

COALESCE(<expression>, 0)

The example returns the result of the expression, unless it is null, then it returns zero (0).

Coalesce takes an arbitrary number of arguments and returns the first not null value or null if all arguments are null.

Nullif — Map a Single Value to null

SQL’s nullif maps one particular value to null. If the first argument equals (=) the second one, the result is null. Otherwise the first argument is passed through.

NULLIF(<expression>, <expression>)

Case — Map Multiple Values to null

The general case expression can be used for other cases—e.g. to map multiple values to null:

CASE WHEN <expression> IN (…)
     THEN null
     ELSE <expression>

Of course, you can use other comparisons in the case expression as well: >, <, between and so on.

Null Propagates Through Expressions

Expressions and functions that process a null value generally return the null value.4 Noteworthy exceptions are aggregate functions and—due to the three-valued logic of SQLtwo logical operations.5

The result of the following expressions is therefore null:

1 + NULL
'foo ' || NULL || 'bar'

Exceptions: Oracle and SQL Server Databases

The Oracle database treats an empty string as null and vice versa: on the one hand, '' IS NULL is true, on the other hand is null treated as an empty string in string concatenations (||). The Oracle databases returns 'foo bar' for the second example above.

SQL Server has the deprecated setting SET CONCAT_NULL_YIELDS_NULL OFF to treat null as an empty string when concatenating strings with the + operator.

Note: Non-Standard Functions

Most databases support more functions than specified by the SQL standard. These functions may or may not follow the general idea that null propagates.

The concat() function for string concatenation is an important example because many databases support it. They nevertheless handle null in the input differently: Db2, MySQL and MariaDB act in the spirit of the SQL standard and return null. H2, Oracle, PostgreSQL, and SQL Server treat null in the input to concat() as empty string.

In logical expressions (and, or, not), null is the same as the third truth value unknown.6 Null (unknown) only propagates through logical expressions if the result becomes undecidable due to a null operand. That means that there are two cases in which the result is not null, although one operand is null: Null and false is false because a logical conjunction (and) is false as soon as a single operand is false. The analogous logic applies to null or true. See Logical Operations Involving Unknown for more details.

Null in Aggregate Functions (count, sum, …)

Aggregate functions generally remove null values from their input before performing the aggregation.7 That means that the result of an aggregate function does not necessarily become null if the input contains null values. This behavior is most often used to implement pivot queries.

Think About It

How does the propagation of null through expressions and the removal of null values prior to aggregation affect the following expressions:

SUM(a) + SUM(b)

The result of an aggregate function is only null if it operates on an effectively empty set. This is the case if (1) all rows are removed (because they are null values or due to a filter clause⁠), or (2) an explicit or implied group by () is applied to an actually empty set.8

Count and regr_count never return null. These functions return the numerical value zero (0) for an effectively empty set.9

Aggregate functions that return structured data (array_agg, json_objectagg, json_arrayagg, xmlagg) do not remove null values.10

Null in Distinct, Group by, Partition by, Union, etc.

Grouping operations use distinct comparisons to check whether two values belong to the same group.11 Consequently, all null values are put onto a single group.

This also affects operations that are specified in terms of grouping: distinct (in select or in aggregates), partition by, union (without all), etc.12

Null in Unique Constraints

Unique constraints treat null as different to everything—i.e. different to null and different to other values.13 This makes every null a different null so that unique constraints accept multiple null values.

Exceptions: SQL Server and the Oracle Database

SQL Server treats null values as being equal in context of unique constraints: only one null is allowed per column.

The Oracle database only accepts multiple null values in context of unique constraints if all columns of the supporting index are null. If one column is not null, only a single null is accepted for each of the other columns. See “Indexing null in the Oracle database” on Use The Index, Luke!

Null in Order By

The SQL standard leaves the sorting of null values relative to non-null values up to the vendors:14 null values may sort before or after non-null values (see Compatibility).

SQL:2003 introduced the order by modifier nulls (first|last) so that SQL developers have explicit control where null values appear. This is still not widely supported (see Compatibility).

     [ , <expression> [ASC|DESC] [NULLS (FIRST|LAST)] ]

The effect of nulls (first|last) can be obtained with a case expression in all databases. The following example implements order by c nulls first:

              THEN 0
              ELSE 1
       , c

Note that the case expression defines a new order by key for the sole purpose of separating null and not null values.


Null has been part of the SQL standard from the beginning. Support for unique constraints on possibly null columns was required by intermediate SQL-92. Since SQL:1999 it is an optional feature (T591).

SQL:2003 introduced null ordering (nulls (first|last)) as part of the optional feature T611, “Elementary OLAP operations”.

Availability of Features coping with SQL NULL

NULL in SQL: Indicating the Absence of Data” by Markus Winand was originally published at modern SQL.


November 23, 2017

Craig Mullins

Happy Thanksgiving 2017

Today, November 23rd, in the United States of America, we celebrate Thanksgiving by gathering together with our loved ones and giving thanks for what we have.  Typically, this involves celebrations with food, traditionally a big turkey dinner with stuffing, mashed potatoes and gravy, as we watch a parade and football games. I plan to follow this tradition to the letter this year and I wish...

(Read more)

November 21, 2017

Leons Petrazickis

Python Library of the Day: retrying

I’ve learned through extensive experience that Bash is the wrong choice for anything longer than a few lines. I needed to write a command line app, so I put one together in Python —...

(Read more)

Robert Catterall

Db2 12 SQL Enhancement: Temporal Logical Transactions

Temporal data support, introduced with Db2 10 for z/OS, is one of the more interesting SQL-related Db2 enhancements delivered in recent releases of the DBMS. Temporal data support comes in two flavors (which can both be utilized for a single table): business-time temporal and system-time temporal. With business-time temporal support enabled for a table, an organization can put future changes into the table (e.g., price changes for products or services that will not go into effect until...

(Read more)


The Evolution of Db2 Compression

You don't hear much about data compression these days, but recently I encountered a customer who was curious about it. He said his company never used compression due to the belief that because the CPU overhead was too high, but he was wondering if the feature has improved, and if so, how can you determine which tables will benefit from compression?

November 17, 2017

Data and Technology

SQL Coding and Tuning for Efficiency

Coding and tuning SQL is one of the most time consuming tasks for those involved in coding, managing and administering relational databases and applications. There can be literally thousands of...

(Read more)

November 14, 2017

Leons Petrazickis

Kudos to Firefox team on Quantum release

The new Firefox Quantum release is incredibly fast. It feels faster than Chrome, faster than old Firefox, and faster than all the other browsers on my Macbook. Impressively, despite Firefox ditching...

(Read more)

Kim May

Webinar Thursday: Calling IBM Sellers with Q4 Deals!

Sirius/XM already has the Holly channel playing Christmas music and Halloween was just a couple weeks ago. It’s way too early!  But…the clock IS ticking and there really are only 4 solid weeks left...

(Read more)


The Future of Db2 Documentation: More PDFs, More Frequent Updates.

As I've noted a few times, I maintain a PDF library of Db2 for z/OS documentation. I just find it easier to search PDF docs as opposed to looking up information online.

Henrik Loeser

Latest News on Bluemix and IBM Cloud

IBM Cloud News Sometimes it's quite hard to keep an overview of what is going on with the IBM Cloud. I had been out on vacation and needed to catch up. Want to learn with me? Here is some of the...

(Read more)

November 13, 2017

Craig Mullins

The Db2 12 for z/OS Blog Series - Part 19: Profile Monitoring Improvements

The ability to monitor Db2 using profile tables is a newer, though by no means brand new capability for Db2 DBAs. You can use profile tables to monitor and control various aspects of Db2 performance such as remote connections and certain DSNZPARMs. But this blog post is not intended to describe what profile monitoring is, but to discuss the new capabilities added in Db2 12 to enhance profile...

(Read more)

November 11, 2017

Henrik Loeser

Use Db2 as Cloud SQL Database with Python

Load Data into IBM Db2 on Cloud Over the Summer I learned that Python is top in the IEEE programming languages ranking. It is also my favorite language for quickly coding tools, web apps and...

(Read more)

November 10, 2017

DB2Night Replays

The DB2Night Show #198: The 5 W's of Db2 HADR with guest Dale McInnis, IBM

@dalemmcinnis Special Guest: Dale McInnis STSM / NA Data Server Tech Sales IBM Canada The 5 W's of Db2 HADR 98% of our audience learned something! What is HADR? Why should you use HADR? Where should HADR be deployed? When should you use HADR? Who is using HADR? And, bonus, How is HADR being used by Db2 Customers? Our live audience was HUGE- clearly HADR is an important, and popular, topic of concern for the Db2 community! Watch and...

(Read more)

November 09, 2017

Leons Petrazickis

Cryptocurrency and irreversible transactions

There’s a current news story about a wallet blunder freezing up $280,000,000 of Ether, a cryptocurrency. I try to avoid posting too much opinion on my blog, but I do have a view on this....

(Read more)

November 08, 2017

Henrik Loeser

EU Cloud: IBM gives client full control over their data

IBM Cloud: Have full control over your data Today, IBM announced for December the roll-out of a new support model and capabilities for IBM Cloud. Based on the announcement IBM is in the process of...

(Read more)

Subscribe by email



planetDB2 is an aggregator of blogs about the IBM DB2 database server. We combine and republish posts by bloggers around the world. Email us to have your blog included.