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
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
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN