On Wed, 12 Oct 2016 18:53:29 -0500, Janet Graff <janet.gr...@yahoo.com> wrote:

>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.

Thanks for the info. It helps a bit, but not enough. 

First, just to make sure you know, you can't do a RACROUTE REQUEST=VERIFY while 
running in cross-memory mode. You would need to create a request for another 
task running in your server primary, queue the request to the task, and suspend 
the cross-memory task until you have an answer.

Next, doing a VERIFY for a user ID is not  really sufficient in the general 
case, as there are many other aspects of the user's security environment that 
could affect the answer to an authorization check (group name, terminal name or 
other port of entry, SECLABEL etc.). At a minimum you should use the UTOKEN as 
input to the VERIFY (if you have to create a new ACEE) but even that is not 
sufficient in some cases. So, if you're doing this for a product (as opposed to 
a bit of home-grown code just for your own company's use) then you need to 
rethink how much data you capture. For example, it may be much better to use a 
RACROUTE REQUEST=EXTRACT TYPE=ENVRXTR to get a copy of the user's ACEE, and 
then recreate it in your address space using RACROUTE REQUEST=VERIFY that 
specifies ENVIRIN.

But even before that, what kind of checks do you plan to make using the ACEE 
once you have it? (What resource class, for example?) If you're lucky they will 
be checks that you could perform using the existing user's ACEE rather than 
rebuilding one. That would be both more efficient, and give you a much simpler 
overall design.


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