>It would help to know why you want to do that, and what you intend to do after 
>you have the ACEE. It's possible that there are alternatives that >would be 
>better, which we might recommend if  we had some more information.

>However, you don't _need_ a  TERMID unless you're doing a RACROUTE 
>REQUEST=VERIFY for a user's TSO session. It's certainly not related to the 
>>error message you're getting, which is quite clearly due to an invalid user 
>ID. You probably got that error message because you've said that the >ength of 
>the user ID is 8, but MYUSER is only 6 characters long. That won't work.



I am writing a test program for a system level task.  The system level task 
accepts cross memory service calls from various address spaces including CICS, 
IDMS and IMS so it needs to be able to handle secondary ACEEs.  Instead of 
bringing up a more complicated subsystem in my automation tests I'd like to 
write a neat standalone assembler program that creates a secondary ACEE and 
then uses it to make the cross memory services call.

With your's and Charles' help I now have the ENVIR=CREATE working and I've 
determined that the ENVIR=CHANGE does me no good because it can only modify the 
GROUP and the not the userid.

I expected that the ENVIR=CREATE would create the ACEE and start using it.  
However I'm still getting indications after the ENVIR=CREATE that the cross 
memory services call is still using the initial userid and not the userid from 
the secondary ACEE.

Is there another step I should do before performing the cross memory services 
call to make the new ACEE active?  I also expected to get a message from RACF 
indicating the switch to the new ACEE with maybe an ICH message showing the new 
userid, which I'm not getting and is leading me to believe that I haven't 
actually switched to the new ACEE.


For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to