I believe this is documented in the "What's New" for V5R3 - you might go to www.iseries.ibm.com/infocenter and pick the V5R3 link and then click on what's new on the right. If I remember correctly, that is. ;-) -------------- Original message -------------- From: Dan <dan27649@xxxxxxxxx>
This is *not* a critical item, more of a "would be nice to" and even a curiosity thing. My immediate fix is to have the command just call a CL that issues the WRKMBRPDM command. 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). Both the original WRKMBRPDM and my new WMPU command objects have "Object domain: *SYSTEM", "Allow change by program" is YES for my command and NO for the IBM command. The IBM command object is "Digitally signed" with "System-trusted source", whereas mine is not. (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 also tried duplicating the WRKMBRPDM object to my named command, tried CHGCMDDFT CMD(WMPU) NEWDFT('FILE(DANDEVLIB/DANDEV)'), but this doesn't work because "No default value exists for specified qualifier.") TIA, Dan -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.