In two previous articles, I dealt with some program design practices that can cause performance problems. Today, I deal with another area where large variables can have a derogatory impact on performance, and I show you a couple of ways to get around the problem. I use RPG for my examples, but the principle applies to any language.

Let’s say we need three string-handling subprocedures–I’ll call them DoThis, DoThat, and DoTheOther–that will be used in many programs. Since they’re used so widely, let’s put them into a service program. Let’s say further that each of these subprocedures accepts two 64K

This year, I will be on the AS/400 platform for 19 years. Wow–where did that time go? All those years working with peers, customers and the like, I’m convinced that the performance component that is the most misunderstood, is memory. In a previous article, I explained about the importance of the machine pool and we looked at the Performance Adjuster feature of i5/OS as well. The feedback I received from that article proved to me that we need more articles on managing memory.

I would like to share some neat tricks of the trade and best practice techniques that

Since processing time immemorial, i5/OS and OS/400 computers have had problems with default passwords. Default passwords occur when a user password is equal to its corresponding user profile name. They are mostly created by the system’s user creation commands, and i5/OS administrators can spend a lot of time finding and changing these hacker magnets. This week, I’ll examine the dynamics of System i default passwords and how they are created.

Today’s article is part one of a two-part series exploring default passwords and their creation, detection, and prevention. This week, I’ll explore the mechanics of how default passwords are created