When we look at modernizing (or writing new) applications, one of the basic principles is to tier the application, i.e., separate the interface, the business logic, and the database processing. The concept is that any of the components can be changed without affecting the others and, more importantly, you can have multiple interfaces making use of the same business logic and database routines.

That’s all well and good, but there are a couple of minor hiccups that have to be handled. What happens when a business logic or database routine hits an error? How does it notify the interface that

Our inventory items are assigned seven-digit numbers. When we accept an order for a custom product, we assign it a number, build the product, ship it, and retire the number. After a few years, the system automatically purges these numbers, which means we are free to reuse these numbers. Is there a way to make an SQL query find the numbers within a range that are not assigned to items?

–Tim

I’ll give you a method that works at V5R4 or above, Tim.

Let’s say your database file is IBM‘s famous QIWS/QCUSTCDT, and that you want to find available

This week, I’m demonstrating a technique for protecting your system security setup from unauthorized changes by other i5/OS administrative users. Introduced in i5/OS V5R2 and located inside System Service Tools (SST), there is an operating system configuration that lets you lock down security settings so that no users can change your preset i5/OS security scheme. Here’s how it works.

Why Lock Down Security Changes?

The main reason for shutting down your security scheme is for. . . well, security. Your iSeries, System i, or Power i box may reside in a regulated environment where only one or two security officer