In my previous tip on the new free-form RPG support I discussed the basics of the new methods for defining data in RPG. In this tip I will be covering some additional aspects of the new style data definitions that are not so obvious from a simple reading of the documentation.

More on Data Definitions

Until now, if you wanted to ensure that all fields of a specific type (currency for example) used a common definition, you used the LIKE keyword. The one small problem with this was that you could not change the data type of the cloned field.

In this tip about new DB2 for i 7.2 features, I’m going to cover some noteworthy news about user-defined function (UDF) features. The feature list includes how a function name is now resolved based on casting rules, named parameters, parameter defaults and array parameters.

Function Name Resolution

From the earliest days of V4R4 when user-defined functions became available, I’ve had a BIG pet peeve. That pet peeve is how DB2 tries to figure out what function you want to use.

For a little background, remember that a function can be overloaded. That means scalar UDF ConvertDate can be defined

After publishing my latest article on improving IBM i journal performance with journal caching, IBM Rochester Software Engineer Chad Olstad wrote in with the following comment, which expands on journal caching and offers an alternate view of journal caching’s relationship with commitment control.

“I wanted to point out the one thing you did not mention in the article is the cache sweeper knob, which controls how [old] stale cached journal entries are allowed to be before they are flushed to disk. [The cache sweeper knob] can be customized by the user as of V6R1 via [the Change Journal Attributes