Admin Alert: Dissecting the Unusual QLGPGCMA.LOCALE Error

One of my i5/OS partitions went haywire recently. Suddenly, some users couldn’t run Infor‘s SSA ERP LX package, an i5 Domino server wouldn’t reboot, and some users couldn’t sign on. These problems occurred because of an authority problem involving an i5 object named QLGPGCMA. This situation is commonly referenced on the Internet, but there isn’t much information about its cause. The good news is that once the problem is diagnosed, it’s fairly easy to cure.

Diagnosing the Problem

The QLGPGCMA.LOCALE problem is very simple. When it occurs, some of your once reliable applications and i5/OS features may simply stop working. They may refuse to let anyone start or use them and they display the same error messages when failing. This article documents what I know about this problem and its possible solutions. If anyone has more information about this issue, please feel free to email me using the IT Jungle Contact form, which you can get to by hitting the Contact button at the top of this page. I may use your info in a future Admin Alert column.

QLGPGCMA is an i5/OS locale object (*LOCALE) that contains information about how data should be processed, printed, or displayed on the system. In IBM documents and error messages, it is also referred to as QLGPGCMA.LOCALE. There are many different *LOCALE objects on the system, including one for each language that is supported on a partition.

While the QLGPGCMA.LOCALE problem may occur in several different i5 applications and functions, the available documentation indicates that it may be most prevalent in the following i5 areas:

• Application packages that use *LOCALE objects to determine how data is processed, printed, and displayed in different languages
• Within a Domino for iSeries server
• Within the MQSeries for iSeries Queue Manager
• When starting remote writers on the system
• When signing on to an i5 partition

There may be other unreported scenarios where this problem rears its disgusting head, but wherever the problem occurs, it exhibits three familiar symptoms. First, an application or function (or several different applications and functions) will start malfunctioning or fail to start up altogether. While these situations might seem like an application issue (or possibly object corruption), the problem really is an authority issue, particularly if you see two or more applications failing to initialize correctly on the same partition.

The second problem symptom is that the application will usually fail with the following severity 40 error message:

CPFA09C – Not authorized to object. Object is /QSYS.LIB/QLGPGCMA.LOCALE

If you see this message associated with a failing application, you are probably experiencing the QLGPGCMA.LOCALE problem.

The third give-away involves those users who suffer from the issue. If you discover that certain users are unable to run your failing application or function while other users can run it, that pattern could be definitive proof that your system is suffering from this problem. During your investigation, you may find that users who possess All Object authority (*ALLOBJ) in their user profile will be able to run the failing program, while those users who do not possess *ALLOBJ authority cannot run the function.

So if you discover that certain users are having problems accessing applications or functions that were previously available, that the CPFA09C error is present for the QLGPGCMA.LOCALE object, and that the problem only affects users who do not have *ALLOBJ authority, then you most likely have the QLGPGCMA.LOCALE problem on your partition. But don’t be alarmed, diagnosis is a good thing because it can lead to an easy cure.

The Deceptive Solution

The worst part about this problem is that the issue may not be located where you think it is. Because the CPFA09C message refers to the QLGPGCMA.LOCALE object (which can be found in the i5 system library, QSYS), most people’s first impulse is to check and adjust that object’s authorization list by using the following Edit Object Authority command (EDTOBJAUT):

EDTOBJAUT OBJ(QSYS/QLGPGCMA) OBJTYPE(*LOCALE)

However, this approach will disappoint you because on most systems, the *PUBLIC user already has *USE authority to that object. Many people in this situation will then change QLGPGCMA’s *PUBLIC authority to *CHANGE or *ALL, but that usually doesn’t solve the problem because the user probably doesn’t need to update a *LOCALE object in the course of starting an application. My experience is that the CPFA09C message may be a red herring here; its presence can alert you to the problem, but it doesn’t pinpoint its solution.

Based on what I have experienced and what I’ve read about, QLGPGCMA.LOCALE is definitely an authority issue that can be solved in one of the following three ways:

1. By checking and changing *PUBLIC authority to the Root (/) directory of the AS/400 Integrated File System (AS/400 IFS)
2. By checking and changing *PUBLIC authority to the QSYS.LIB file system in the AS/400 IFS. QSYS.LIB is used to house your native DB2 for i5/OS file system.
3. By providing *ALLOBJ authority to all users who need to access the problem application or feature (not recommended).

Here’s how you would use each of these solutions to solve the problem.

Getting to the Root (/) of the problem

In my situation and some other situations posted on the Internet, this problem was solved by checking and changing the *PUBLIC user authority to the Root (/) directory on the AS/400 IFS. On the green screen, you can check your Root (/) authority by performing the following steps:

1.  Execute the Work with Object Links command (WRKLNK) to view the Root (/) directory of the AS/400 IFS.

WRKLNK OBJ(‘/’)

2.  In front of the AS/400 IFS directory object (specified by a single ‘/’), enter a ‘9’ to work with the Root (/) object’s authority.

3.  If *PUBLIC authority is equal to *EXCLUDE, place a ‘2’ in front of the *PUBLIC entry, press enter and add the following authorities for the *PUBLIC user:

Under the New Data Authorities parameter (DTAAUT), enter *RWX so that the user has read, write, and execute in the Root (/) directory.

Under the New Object Authorities parameter (OBJAUT), enter the following authorities:

*OBJMGT: Object management authority
*OBJEXIST: Object existence authority
*OBJALTER: Object alter authority
*OBJREF: Object reference authority

4.  Press Enter and save your changes.

On my system, *PUBLIC authority had been changed to *EXCLUDE, which meant that the user had none of these authorities on the Root (/) level. This was probably changed by an over-zealous i5/OS administrator (probably me) or perhaps even by a consultant. And, from reading some of the literature on the Internet, this is a common cause of the problem.

Even though it may seem counter-intuitive to give the *PUBLIC user virtually all authority to the AS/400 IFS Root (/) directory, IBM recommends that you do this in order for your users to access necessary system objects that they need to run their applications. The way one IBMer explained it to me was that, on all the other file systems and objects that reside under the AS/400 IFS Root (/), these systems have authority settings of their own that override their parent Root (/) settings. So as illogical as this may sound, giving the *PUBLIC user full authority to the Root (/) directory doesn’t grant unlimited system access to your users, and these authorities appear to be a legitimate configuration for your i5 system.

On my system, changing *PUBLIC authority to the Root (/) directory solved the QLGPGCMA.LOCALE problem and my users were able to sign on again and to run their applications. There are other reports from IBM and other sources where they recommend doing this exact same security change in order to solve this issue. If you browse the Internet, you’ll see this fix listed in support bulletins and forum postings covering Domino for i5 problems, printer problems, and MQSeries problems.

As to why this problem doesn’t affect i5/OS users who have *ALLOBJ authority, I suspect it is because *ALLOBJ authority gives those users the right to access any system resource without having to be explicitly authorized to that resource in the object’s access list. Unlike ordinary *PUBLIC users, these users don’t need to rely on their Root (/) access to access system resources; they have all the authority they need in their own user profiles.

The QSYS.LIB Solution

In some reports, it is also recommended that *PUBLIC may need to be explicitly authorized to the DB2 for iSeries file system, which is the native i5/OS database file system residing under the /QSYS.LIB file system in the AS/400 IFS. To check your authorizations for this file system, execute the following WRKLNK command to view QSYS.LIB:

WRKLNK ‘/QSYS.LIB’

Take an option ‘9’ (Work with authority) from the screen that appears and make sure that someone hasn’t change the following *PUBLIC authorities to this file system:

Under the New Data Authorities parameter (DTAAUT), *PUBLIC should have *RX authority so that your users have read and execute rights to the QSYS.LIB file system. Unlike the Root (/) authorities, *RX are the only authorities *PUBLIC needs to access features and programs on the system. According to most sources I could access, it appears that the *PUBLIC user should not possess any additional authorities to QSYS.LIB beyond the *RX data authorities (which are also his default authorities). If someone changed your *PUBLIC user’s authorities to *EXCLUDE, make sure that you only give them back these data authorities–nothing else. And that change may solve the QLGPGCMA.LOCALE problem.

Providing *ALLOBJ to User Profiles–the Unwise Solution

While it appears that most QLGPGCMA.LOCALE problems can be solved by performing one or both of the configurations above, there is an additional way to solve the problem; but this solution should only be used by very wise or very foolish administrators. The thinking on this answer states that since people with *ALLOBJ authority aren’t affected by this situation (as described above), if you give *ALLOBJ authority to all the users who are experiencing this issue then you will quickly solve the problem.

It doesn’t take Steven Hawking or even Paris Hilton to find the flaw in that logic. You may solve your immediate problem with QLGPGCMA.LOCALE, but by passing out *ALLOBJ authority like AOL CDs in the 1990s, you will permanently torpedo your i5/OS security. Normally, I wouldn’t even mention this solution, but I found one IBM technical bulletin that recommends giving *ALLOBJ to users as a circumvention while the problem was being investigated, so I wanted to warn you about it. Besides its obvious security implications, a second problem is that once you give users *ALLOBJ authority, it becomes incredibly hard to take it away. So it’s best to stay away from this solution, if you can.

As both a victim and a researcher of this problem, I can tell you that the QLGPGCMA.LOCALE problem is frustrating. Hopefully, the information I gathered for this article will help you quickly diagnose and solve this issue before it affects company productivity.