MCH6801: Object domain or hardware storage protection violation

What it means

Every object on IBM i belongs to a domain, either system or user, and that domain never changes. Most object types are created in the system domain. IBM's API documentation explains that at security levels 40 and 50, system-domain objects can only be reached through the commands and callable APIs IBM provides. Programs also run in a state. Application programs run in user state, and parts of the operating system run in system state.

When a user-state program tries to use a system-domain object directly, for example by getting a pointer into its storage and reading it with machine interface instructions, the machine stops it and sends MCH6801. The message help gives a violation type, and type 1 means an object domain violation. The same message also covers hardware storage protection, where the storage itself is marked as off limits to the program.

At security level 30 and below the domain check isn't enforced the same way. That is why code that ran for years can fail after a move to level 40, or on another partition at a higher level. On the midrange.com MI400 list, a contributor pointed out that a new QSECURITY value takes effect only at the next IPL, so the system value can read 30 while the system still runs at another level.

Common causes

• An application or tool program uses machine interface instructions or pointer tricks to read a system-domain object, such as a binding directory or a message file, instead of using an API.
• The system was moved to security level 40 or 50, or the program was copied to a partition running at a higher level, and the program was written for level 30.
• A user-state program called a system-state program or command in a way only system-state code may. One case on the MI400 list involved an IBM compiler command, and the poster suspected his copy of the command was damaged.
• A program created a user space or user index in the system domain, then tried to use it directly through a pointer, which works only for user-domain objects.

How to find the problem

1. Run DSPJOBLOG, put the cursor on MCH6801 and press F1, then F9. Note the violation type, the object, and the program and statement that failed.
2. Check the security level the system is really running at. Display system value QSECURITY with DSPSYSVAL QSECURITY, and remember that a change made since the last IPL isn't active yet.
3. Look at the failing statement. Direct pointer access to an object, MI built-ins, or calls into IBM programs that aren't documented APIs are the usual signs.
4. If an IBM program or command is named, check whether the object was restored from another system or release, and compare it with a known good copy.

How to fix it

• Replace direct access with the supported command or API. For example, a contributor on the midrange.com MI400 list suggested DSPBNDDIR with an outfile instead of reading a binding directory's space.
• Create user spaces and user indexes in the user domain, in a library that system value QALWUSRDMN allows, if the program must use them through pointers.
• Ask the vendor for a level 40 compatible version of any package that fails after a security level change. Test packages at the new level before changing production.
• Reinstall or re-restore an IBM product whose command or program is named, if it appears damaged.
• Don't lower the security level to make one program run. Fix the program.

DSPMSGD MSGID(MCH6801) MSGF(QSYS/QCPFMSG)

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your IBM i release.