... At v5r2 in another shop (I think they were at security level 40, but could have been 30), I retrieved the source for WRKMBRPDM into a different named member (WMPU), changed the file parameter to default to my development source file, compiled and life was good. In a new shop now, at v5r3 and security level 40, I try to do the same thing; the command compiles, but running and even prompting the command generates MCH6801, violation type 1 (Object domain violation).
Dan, what does DSPCMD show for the "State used to call program" for your command? I think that your version will show *USER; that would cause the domain violation because QPDA/QUOCPP requires that it be called in system state. (You won't be able to create a command that calls the CPP in system state.) ===> DSPCMD QPDA/WRKMBRPDM Program to process command . . . . . . : QUOCPP Library . . . . . . . . . . . . . . : QPDA State used to call program . . . . . : *SYSTEM <-------
... (My immediate fix is to have the command just call a CL that issues the WRKMBRPDM command. So, I have a workaround. I'd just like to know what's going on, and why it's behaving diffferently than before.
I think you'll have to stick with that workaround. What's happening is that security level 40 enforces this rule (from the help for DSPSYSVAL QSECURITY): "Programs fail if they try to access objects through interfaces that are not supported."