Junior J. Programmer modifies an RPG program. His testing works properly. The user’s test works properly. The user approves the change, the modified program is installed, and everything is copasetic until a few months later when the program gets stuck in a loop. What happened, and why is Junior not entirely to blame?

Here’s the code Junior added to the program:

C     1             DO        5             X                 1 0
C                   EXCEPT    PLINE
C                   ENDDO

What could go wrong with such simple code?

It turns out that the subroutine that contains Junior’s code is also conditionally and indirectly executed from another part

We have two environments: a homegrown system for financials and a canned ERP system for manufacturing. We have written a service program containing subprocedures that access manufacturing data. This service program is stored in a library that is in the manufacturing system’s library list, but is not in the financial system’s library list. Now we need a financial program to use a routine from this service program.

We add manufacturing libraries to the end of the finance library list when we create the finance program so the compiler finds the service program and binds to it. It would be nice

Handling user profile authorities is one of the more critical i5/OS administrative duties. In particular, there are three crucial user parameters that must be set up correctly to prevent your users from inadvertently accessing objects and functions that they should not be using. Today, I’ll look at how you can work with these values to prevent several avoidable security pitfalls.

The Hierarchy of User Authority

Before you can work with user authorities, you must understand what they do. Here is the basic hierarchy of user profile security settings and how they relate to each other.

1. System privileges–Eight user profile