Capturing a reply id from a WTOR

[Steve Arnett]

Folks,

   First, I am cross posting this to both the ALC and Main boards, so I 
apologize for those of you that receive it twice.


   Second, I have a program that issues a WTOR.  Presently, I capture 
that WTOR with automation and issue a modify command to another address 
space with the reply id for the WTOR.  I would like to bypass the 
automation piece and issue the modify command directly from the program 
issuing the WTOR.  However, I see no description of how on might do this 
in the manuals.  I have also begun searching the archives for the 
answer.  How do you extract the reply id from a WTOR once the WTOR has 
been issued? 
   My code would look something like this:


WTOR  MF=(E,WTORSTOR)   ISSUE WTOR
*
*   Extract the reply id for the command below   

* 
XCMGCRPL(MGCRLTH),MGCRPL   CLEAR PARM LIST   
MVC   MGCRTEXT(14),=CL14'F STCNAME1,xx '  
*
MVC   MGCRTEXT+11(2),DBLWRD+3  MOVE IN REPLY NUMBER
*
MVC   MGCRTEXT+14(xx), REMAINDER OF 
COMMAND  
LAR1,(MGCRTEXT-MGCRPL)+65  GET MGCRPL LENGTH 
STC   R1,MGCRLGTH  PUT LGTH IN THE MGCRPL
MODESET KEY=ZERO   * KEY ZERO/SUPERVISOR STATE   
SRR0,R0CLEAR R0  
MGCR  MGCRPL   ISSUE COMMAND 
MODESET KEY=NZERO  * KEY ZERO/SUPERVISOR STATE   
* 
LAR1,WTORECBWAIT FOR REPLY   
WAIT  1,ECB=(R1)*


Thanks in advance,
Steve A.

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

Re: Capturing a reply id from a WTOR

[Binyamin Dissen]

On Thu, 29 Dec 2005 13:45:27 -0600 Steve Arnett <[EMAIL PROTECTED]> wrote:

:>First, I am cross posting this to both the ALC and Main boards, so I 
:>apologize for those of you that receive it twice.

:>Second, I have a program that issues a WTOR.  Presently, I capture 
:>that WTOR with automation and issue a modify command to another address 
:>space with the reply id for the WTOR.  I would like to bypass the 
:>automation piece and issue the modify command directly from the program 
:>issuing the WTOR.  However, I see no description of how on might do this 
:>in the manuals.  I have also begun searching the archives for the 
:>answer.  How do you extract the reply id from a WTOR once the WTOR has 
:>been issued? 
:>My code would look something like this:

:> WTOR  MF=(E,WTORSTOR)   ISSUE WTOR
:>*
:>*   Extract the reply id for the command below   
 
:>* 
:> XCMGCRPL(MGCRLTH),MGCRPL   CLEAR PARM LIST   
:> MVC   MGCRTEXT(14),=CL14'F STCNAME1,xx '  
:>*
:> MVC   MGCRTEXT+11(2),DBLWRD+3  MOVE IN REPLY NUMBER
:>*
:> MVC   MGCRTEXT+14(xx), REMAINDER OF 
:>COMMAND  
:> LAR1,(MGCRTEXT-MGCRPL)+65  GET MGCRPL LENGTH 
:> STC   R1,MGCRLGTH  PUT LGTH IN THE MGCRPL
:> MODESET KEY=ZERO   * KEY ZERO/SUPERVISOR STATE   
:> SRR0,R0CLEAR R0  
:> MGCR  MGCRPL   ISSUE COMMAND 
:> MODESET KEY=NZERO  * KEY ZERO/SUPERVISOR STATE   
:>* 
:> LAR1,WTORECBWAIT FOR REPLY   
:> WAIT  1,ECB=(R1)* 

IEECUCM
IHAORE

Now do it.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Capturing a reply id from a WTOR

[McKown, John]

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 .

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

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Re: Capturing a reply id from a WTOR

[Steve Arnett]

Thanks for the replies...Bottom line was to chase the ORE.  Code looks 
something like this:


*
LAR8,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  
ORELPC R4,8(R9)  COMPARE TCB ADDRESS 
BEFNDOREYES, THIS IS OUR ORE
CLC   0(4,R9),=F'0' CHECK FOR ZERO LINK POINTER 
BENFDOREYES, BYPASS COMMAND 
L R9,0(,R9) GET NEXT ORE
B ORELP TEST IT 
FNDORE   DS0H*   
*

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

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

Re: Capturing a reply id from a WTOR

[Steve Arnett]

Thanks for the replies...Bottom line was to chase the ORE.  Code looks
something like this:

*
LAR8,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
ORELPC R4,8(R9)  COMPARE TCB ADDRESS
BEFNDOREYES, THIS IS OUR ORE
CLC   0(4,R9),=F'0' CHECK FOR ZERO LINK POINTER
BENFDOREYES, BYPASS COMMAND
L R9,0(,R9) GET NEXT ORE
B ORELP TEST IT
FNDORE   DS0H*
*
*
*
NFDORE DS  0H
   MODESET KEY=NZERO

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

Re: Capturing a reply id from a WTOR

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 12/29/2005
   at 01:45 PM, Steve Arnett <[EMAIL PROTECTED]> said:

>Second, I have a program that issues a WTOR.  Presently, I
>capture  that WTOR with automation and issue a modify command to
>another address  space with the reply id for the WTOR.  I would like
>to bypass the  automation piece and issue the modify command directly
>from the program  issuing the WTOR.  However, I see no description of
>how on might do this  in the manuals.  I have also begun searching
>the archives for the  answer.  How do you extract the reply id from a
>WTOR once the WTOR has  been issued?

I'm not sure that you can, reliably, but perhaps you're asking the
wrong question. Why are you issuing a WTOR? Is that really the best
way to achieve what you want to do?

[1] Depending on the context, chasing the ORE chain might not be
reliable.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Capturing a reply id from a WTOR

[Steve Arnett]

The WTOR is issued so that my "other" address space has a hook to notify 
the originator that the function is complete.  In this case, an HSM 
recall issued to another LPAR.  The originator is a front end to the HSM 
communications SVC.


Shmuel Metz (Seymour J.) wrote:


I'm not sure that you can, reliably, but perhaps you're asking the
wrong question. Why are you issuing a WTOR? Is that really the best
way to achieve what you want to do?

[1] Depending on the context, chasing the ORE chain might not be
   reliable.

 



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

Re: Capturing a reply id from a WTOR

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Steve Arnett
> Sent: Friday, December 30, 2005 12:47 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Capturing a reply id from a WTOR
> 
> 
> The WTOR is issued so that my "other" address space has a 
> hook to notify 
> the originator that the function is complete.  In this case, an HSM 
> recall issued to another LPAR.  The originator is a front end 
> to the HSM 
> communications SVC.
> 

So, as I understand it, the scenario is:

There are two TASKs (STCs). The first STC issues the WTOR (is this the
local HSM?). It then sends the WTOR reply id to the second STC via a
MODIFY command. The first STC then WAITs on the WTOR ECB. The second STC
then takes some action. When the action is complete, the second STC will
do a REPLY using the given replyid. The second STC then waits for
another MODIFY. The first stc "wakes up" and continues at this point.
Rinse, repeat.

>From what you have said, I guess you wrote both sets of software. It is
also obvious that you must be running APF authorized. In this case, I
would do something entirely different. Not that your method is really
bad. Have you considered having 16 bytes of storage in ECSA? This would
consist of four fullwords. The first would be the ASCB address of STC1.
The second would be an ECB. The third would be the ASCB of STC2. The
fourth would be another ECB.
You could then do cross memory POSTs? One STC place its ASCB address in
the first ASCB slot and then WAIT on the first ECB, the other would
place its ASCB address in the second ASCB slot and WAIT on the second
ECB. STC1 would do a cross memory POST on ECB2 instead of a WTOR/MODIFY,
then WAIT on ECB1. STC2 would WAIT on ECB2, do its processing, then
cross memory POST ECB1. This is just a high overview. It would be more
difficult to set up, but once going, it should be easier to do the
actual processing. You could use a system-level Name/Token to
communicate the address of this ECSA storage. Just an idea. Another idea
was some sort of weird double ENQ/DEQ (producer/consumer) processing,
but I cannot figure out exactly how to do it just yet.

P.S. Would you consider changing your email client to not fill in the
"reply to:" address? When you do that, I must remember to remove your
email address from my reply and insert the IBM-MAIN email address in its
place.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
 

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

Re: Capturing a reply id from a WTOR

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Steve Arnett
> Sent: Friday, December 30, 2005 12:47 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Capturing a reply id from a WTOR
> 
> 
> The WTOR is issued so that my "other" address space has a 
> hook to notify 
> the originator that the function is complete.  In this case, an HSM 
> recall issued to another LPAR.  The originator is a front end 
> to the HSM 
> communications SVC.
> 

Steve,

Just found another possibility that sounds like it was designed
especially for what you want to do:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A860/4.11


 Pause, Release, and Transfer (IEAVPSE, IEAVRLS, and IEAVXFR) are
callable services that enable you to synchronize task or SRB processing
with minimal overhead. If you have, for example, an application that
requires two tasks to trade control back and forth, these services
provide efficient transfers of control.

These services, which are available to both unauthorized and authorized
callers in Assembler as well as C or C++, use a system-managed object
called a pause element to synchronize processing of tasks or SRBs. The
services provide the following functions:

* Pause the current task or SRB (Pause service - IEAVPSE)

* Release a paused task or SRB (Release service - IEAVRLS)

* Simultaneously release a paused task or SRB and pass control to it
(Transfer service - IEAVXFR)

* Simultaneously release one paused task or SRB and pause the
current workunit (Transfer service - IEAVXFR)


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
 

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

Re: Capturing a reply id from a WTOR

[SArnett]

Initially, neither program was authorized.  I was using the ARCRPEXT 
exit, which, I believe, is not authorized(AC=0), and letting Control-O 
intercept the WTOR message and format the modify command..  ARCRPEXT 
runs in the HSM address space and some requests were getting through to 
the local HSM, which is a badness.  I changed to using a front end to 
the IGX00024 exit, so I am now running authorized in the local address 
space.  This has some rather intriguing side effects.  The first is that 
I can now stack modify commands.  The ARCRPEXT appears to be single 
threaded.  The second is that, now that I am actually authorized, I may 
as well issue the modify myself, instead of having Control-O intercept it.


As for your PS, I must have it set that way at work, because on my 
machine here at the house, it does not have a return address...


PS.  I have read your second e-mail about Pause, Release and Transfer, I 
will look into their availability in 1.4(my current environment) and, if 
not, play with them in 1.7(my new sandbox).  Thanks for the tip.


McKown, John wrote:


So, as I understand it, the scenario is:

There are two TASKs (STCs). The first STC issues the WTOR (is this the
local HSM?). It then sends the WTOR reply id to the second STC via a
MODIFY command. The first STC then WAITs on the WTOR ECB. The second STC
then takes some action. When the action is complete, the second STC will
do a REPLY using the given replyid. The second STC then waits for
another MODIFY. The first stc "wakes up" and continues at this point.
Rinse, repeat.


From what you have said, I guess you wrote both sets of software. It is

also obvious that you must be running APF authorized. In this case, I
would do something entirely different. Not that your method is really
bad. Have you considered having 16 bytes of storage in ECSA? This would
consist of four fullwords. The first would be the ASCB address of STC1.
The second would be an ECB. The third would be the ASCB of STC2. The
fourth would be another ECB.
You could then do cross memory POSTs? One STC place its ASCB address in
the first ASCB slot and then WAIT on the first ECB, the other would
place its ASCB address in the second ASCB slot and WAIT on the second
ECB. STC1 would do a cross memory POST on ECB2 instead of a WTOR/MODIFY,
then WAIT on ECB1. STC2 would WAIT on ECB2, do its processing, then
cross memory POST ECB1. This is just a high overview. It would be more
difficult to set up, but once going, it should be easier to do the
actual processing. You could use a system-level Name/Token to
communicate the address of this ECSA storage. Just an idea. Another idea
was some sort of weird double ENQ/DEQ (producer/consumer) processing,
but I cannot figure out exactly how to do it just yet.

P.S. Would you consider changing your email client to not fill in the
"reply to:" address? When you do that, I must remember to remove your
email address from my reply and insert the IBM-MAIN email address in its
place.

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

Re: Capturing a reply id from a WTOR

[ibm-main]

Matching on TCB address alone may not be good enough.  You should
probably check the ASID as well.  Better yet, match on DOMID as someone
else suggested.  You should also serialize your use of the OREs.  TFM says
CMS and LOCAL locks should be held.

As others have also mentioned, if you have control of the code, there
are better ways of communicating between address spaces than by using
operator interfaces like WTOR, MODIFY and REPLY.


At 2005-12-29 18:06, Steve Arnett wrote:

Thanks for the replies...Bottom line was to chase the ORE.  Code looks
something like this:

*
LAR8,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
ORELPC R4,8(R9)  COMPARE TCB ADDRESS
BEFNDOREYES, THIS IS OUR ORE
CLC   0(4,R9),=F'0' CHECK FOR ZERO LINK POINTER
BENFDOREYES, BYPASS COMMAND
L R9,0(,R9) GET NEXT ORE
B ORELP TEST IT
FNDORE   DS0H*
*
*
*
NFDORE DS  0H
   MODESET KEY=NZERO


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

Re: Capturing a reply id from a WTOR

[Craddock, Chris]

> Initially, neither program was authorized.  I was using the ARCRPEXT
> exit, which, I believe, is not authorized(AC=0),

That's a non-sequitur. The exit routine (typically) is NOT linked AC(1)
because that is only relevant for job step programs. The exit routine
must be loaded from an APF-authorized library, but that is primarily to
ensure installation control over the software that gets control in exit
points. 

The exit routine's "authorization" is dictated by what ever
environmental state that exists when the exit is entered. Most system
exits are entered in supervisor state (and key zero) and are therefore
able to do anything they want.

I have NO knowledge of HSM, but I would bet large that all of its exits
are entered in supervisor state. If so, you have been solving a
non-problem, lo these many years.

> and letting Control-O
> intercept the WTOR message and format the modify command..  ARCRPEXT
> runs in the HSM address space

Then it almost certainly is entered in sup state... but at a minimum it
would be considered an authorized environment, either by JSCBAUTH being
set as a result of the AC(1) job step program, or by running in a system
key.

> and some requests were getting through to
> the local HSM, which is a badness.  I changed to using a front end to
> the IGX00024 exit, so I am now running authorized in the local address
> space.

Which address space is "the local address space"? The issuer of HRECALL?

> This has some rather intriguing side effects.  The first is that
> I can now stack modify commands.  The ARCRPEXT appears to be single
> threaded.  The second is that, now that I am actually authorized, I
may
> as well issue the modify myself, instead of having Control-O intercept
it.

Or you could just bag the whole idea and implement a reliable signaling
mechanism between HSM and your STC. 

> PS.  I have read your second e-mail about Pause, Release and Transfer,
I
> will look into their availability in 1.4(my current environment) and,
if
> not, play with them in 1.7(my new sandbox).  Thanks for the tip.

Pause/Release services first became available in (I think) OS/390 2.5,
if not earlier. They are available on every currently supported release.
They are also a far superior mechanism for signaling between address
spaces than dinking around with WTORs and (unserialized!!) ORE chains.

You may still need to provide a mechanism for queuing requests from
multiple callers unless (as you surmised) the exit is naturally
serialized by HSM.

CC 

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

Re: Capturing a reply id from a WTOR

[SArnett]

Thanks for the insight.  It is appreciated.

Craddock, Chris wrote:


That's a non-sequitur. The exit routine (typically) is NOT linked AC(1)
because that is only relevant for job step programs. The exit routine
must be loaded from an APF-authorized library, but that is primarily to
ensure installation control over the software that gets control in exit
points. 


The exit routine's "authorization" is dictated by what ever
environmental state that exists when the exit is entered. Most system
exits are entered in supervisor state (and key zero) and are therefore
able to do anything they want.

I have NO knowledge of HSM, but I would bet large that all of its exits
are entered in supervisor state. If so, you have been solving a
non-problem, lo these many years.

Then it almost certainly is entered in sup state... but at a minimum it
would be considered an authorized environment, either by JSCBAUTH being
set as a result of the AC(1) job step program, or by running in a system
key.

Which address space is "the local address space"? The issuer of HRECALL?

Or you could just bag the whole idea and implement a reliable signaling
mechanism between HSM and your STC. 


Pause/Release services first became available in (I think) OS/390 2.5,
if not earlier. They are available on every currently supported release.
They are also a far superior mechanism for signaling between address
spaces than dinking around with WTORs and (unserialized!!) ORE chains.

You may still need to provide a mechanism for queuing requests from
multiple callers unless (as you surmised) the exit is naturally
serialized by HSM.

CC 


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

Re: Capturing a reply id from a WTOR

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 12/30/2005
   at 12:47 PM, Steve Arnett <[EMAIL PROTECTED]> said:

>The WTOR is issued so that my "other" address space has a hook to
>notify  the originator that the function is complete.

You don't need a WTOR for that.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Capturing a reply id from a WTOR

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 12/30/2005
   at 04:19 PM, SArnett <[EMAIL PROTECTED]> said:

>Initially, neither program was authorized.  I was using the ARCRPEXT 
>exit, which, I believe, is not authorized(AC=0),

AC=0 is only relevant for ATTACH with RSAPF. In a normal context, if
the caller is APF authorized then the exit is authorized.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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