Thanks for the replies...Bottom line was to chase the ORE. Code looks
something like this:
*
LA R8,0 GET PSA ADDRESS
L R8,16(,R8) GET CVT ADDRESS
L R8,100(,R8) GET UCM ADDRESS
L R9,28(,R8) GET FIRST ORE
MODESET KEY=ZERO * KEY ZERO/SUPERVISOR STATE
ORELP C R4,8(R9) COMPARE TCB ADDRESS
BE FNDORE YES, THIS IS OUR ORE
CLC 0(4,R9),=F'0' CHECK FOR ZERO LINK POINTER
BE NFDORE YES, BYPASS COMMAND
L R9,0(,R9) GET NEXT ORE
B ORELP TEST IT
FNDORE DS 0H *
*
*
*
NFDORE DS 0H
MODESET KEY=NZERO
McKown, John wrote:
I don't know of a way to do that directly. However, the reply number is
kept in the ORE. The ORE is in subpool 231, which is [E]CSA. Use of the
ORE is definately not GUPI (General User Programming Interface). Upon
return from the WTOR, general register 1 contains an identification
number. I am fairly sure that this is the same as the OREDOMID in the
ORE. ORERPIDB contains the reply number (in hex - DS F). Each ORE is
chained to the next via the ORELKP field. You find the first ORE via the
UCMRPYQ of the UCM, which is pointed to by the CVTCUCB. Serialization is
your worry <grin>.
If you are on z/OS 1.7 (not likely, but maybe), if appears that you can
use the CNZQUERY macro to get the OREs.
--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
