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
