Using Program Calls for Service Address Space

[Jerry McCarthy]

I have been experimenting with using program call's to implement a service
address space in VSE 3.1. Most of the macros to support this exist but as
far as I can tell there is only the zOS documentation and it doesn't always
apply. From what I can discern only non-system LX's are supported and you
can't specify SASN=OLD on an ETDEF. That and the fact that VSE macros don't
support linkage=system makes for an interesting challenge. I have been able
to create and use a program call in a single partition but when I attempt to
do an ETCON in another partition I get a Privileged operation exception even
though I am in supervisor state protect key zero. Can anybody point me in
the direction of any information or documentation that can further my goal
or is this not yet a possibility given the current state of VSE's cross
memory support.

 
Regards,

Jerry McCarthy
CPMG
 

[Martin Truebner]

Jerry,

I have looked into setting up PC and using it, but compared to XPCC
connection it, is way too complicated (and apparently not well
supported/implemented/documented). I have settled for my
cross-partition-communication needs with XPCC and XPOST/XMOVE.

...do an ETCON in another partition I get a Privileged operation exception even
though I am in supervisor state protect key zero.

Maybe you are, but ETCON is a macro that leads you into the deepth of
VSE ---if you get a priv-op althru in priv mode then someone has taken
it away between your call to ETCON and the final incident.

You might want to use the hardware to trace what goes on. SDAID is at
that level pretty useless and unreliable, but VM would be a great tool.
There are other options.... ;-)

Tell us more about what you are about to do...I like to understand why
the simpler methods (to pass information) are no good.

[Jeffrey Barnard]

Jerry,

VSE supports only those PC functions (emulated z/OS features) absolutely
required to get CICS TS to work. No other functions are supported. We have
looked into this in the past and even talked to IBM about it but the
functions supported in VSE are too limited.

You can in fact, setup a space switch PC in VSE. But, you can not do
anything, even SVC's are not supported for a routine running in this mode.
If full space switch PC was supported you could do some very interesting
things but it is not.

If you can define what you need, write a requirement and present IBM with a
business case.

Have fun!

Regards,
Jeff

Post by Jerry McCarthy
I have been experimenting with using program call's to implement a service
address space in VSE 3.1. Most of the macros to support this exist but as
far as I can tell there is only the zOS documentation and it doesn't always
apply. From what I can discern only non-system LX's are supported and you
can't specify SASN=OLD on an ETDEF. That and the fact that VSE macros don't
support linkage=system makes for an interesting challenge. I have been able
to create and use a program call in a single partition but when I attempt to
do an ETCON in another partition I get a Privileged operation exception even
though I am in supervisor state protect key zero. Can anybody point me in
the direction of any information or documentation that can further my goal
or is this not yet a possibility given the current state of VSE's cross
memory support.
Regards,
Jerry McCarthy
CPMG

[Edward Jaffe]

Post by Jeffrey Barnard
You can in fact, setup a space switch PC in VSE. But, you can not do
anything, even SVC's are not supported for a routine running in this mode.
If full space switch PC was supported you could do some very interesting
things but it is not.

z/OS does not allow SVCs to be issued in cross-memory mode either. Any
attempt to do so results in abend0F8! To mitigate the effects of this
restriction, a few basic z/OS services (e.g., STORAGE, WAIT, POST, etc.)
provide a LINKAGE=SYSTEM option, which uses a stacking PC to invoke the
service rather than the traditional SVC method.

Note: Before z/OS 1.6, some services still used "basic" (not "stacking")
PCs. The macro had to issue its own SSARs, the PC routines themselves
issued PCLINK STACK/UNSTACK, it was ugly. Thankfully, this "junk" was
removed when support for reusable ASN was implemented. Basic PC is no
longer used anywhere in z/OS. Stick with stacking PCs if you can...

A typical PC scenario: A client running with HASN=PASN=SASN issues the
PC instruction to request a service from a server. The (stacking) PC
routine begins to run in the client's address space in the mode (e.g.
supervisor state) specified in the entry table and with HASN=client,
PASN=server and SASN=client.

The routine CPOOL GETs or STORAGE OBTAINs a "chunk" of storage which is
owned by the server rather than the client. Using AR mode, the PC
routine has addressability to this storage (primary address space
ALET=0) and its own client storage (secondary address space ALET=1).
ALET=2 gives access to storage in the home space. That's not needed for
this sample. But, if a PC routine calls another PC routine, you might
need ALET=2 to get at something in the original home space like the ASCB
or TCB. The PC routine can also acquire storage in its own address space
for answer areas and the like. (See ALET= and TCBADDR= parameters on the
STORAGE macro for details.)

The PC routines uses CDS (compare double-swap) to queue its request and
POSTs a server-provided ECB. Usually, it will then WAIT for a response
from th server, bit this is not always the case...

A TCB in the server address space wakes up (as a result of the POST),
pulls the request off the queue using CDS, and services the request
using all of the facilities available to ordinary programs running in
task mode under z/OS. When finished, it POSTs the ECB on which the
client is WAITing.

The PC routine wakes back up in the client address space, copies any
result data it might need back to its address space (ALET=1), frees the
storage (or returns it to the pool), and returns to its caller via the
PR instruction. It is now back in the client's mainline with HASN=PASN=SASN.

Post by Jeffrey Barnard
If you can define what you need, write a requirement and present IBM with a
business case.

DB2 on z/OS is a big provider of space-switching, stacking PC services.
SQL clients (in CICS, batch, etc.) will use those PC services to access
DB2 objects. If you have CICS and DB2 running on z/VSE, some dumps might
help shed light on how this is being implemented in z/VSE.

And, if you can run under z/VM, TRACE is your friend...

[Tony Thigpen]

FYI,
It's been a few years since Jeff and I attempted to do SSPCs in VSE, so
my memory may be fuzzy. But, I seem to recall that one common uses of
SSPCs in VSE was when using SMF logging via the DFHEWTM macro.

Tony Thigpen


-----Original Message -----
From: Edward Jaffe
Sent: 07/11/2009 11:18 AM

Post by Edward Jaffe

Post by Jeffrey Barnard
You can in fact, setup a space switch PC in VSE. But, you can not do
anything, even SVC's are not supported for a routine running in this mode.
If full space switch PC was supported you could do some very interesting
things but it is not.

z/OS does not allow SVCs to be issued in cross-memory mode either. Any
attempt to do so results in abend0F8! To mitigate the effects of this
restriction, a few basic z/OS services (e.g., STORAGE, WAIT, POST, etc.)
provide a LINKAGE=SYSTEM option, which uses a stacking PC to invoke the
service rather than the traditional SVC method.
Note: Before z/OS 1.6, some services still used "basic" (not "stacking")
PCs. The macro had to issue its own SSARs, the PC routines themselves
issued PCLINK STACK/UNSTACK, it was ugly. Thankfully, this "junk" was
removed when support for reusable ASN was implemented. Basic PC is no
longer used anywhere in z/OS. Stick with stacking PCs if you can...
A typical PC scenario: A client running with HASN=PASN=SASN issues the
PC instruction to request a service from a server. The (stacking) PC
routine begins to run in the client's address space in the mode (e.g.
supervisor state) specified in the entry table and with HASN=client,
PASN=server and SASN=client.
The routine CPOOL GETs or STORAGE OBTAINs a "chunk" of storage which is
owned by the server rather than the client. Using AR mode, the PC
routine has addressability to this storage (primary address space
ALET=0) and its own client storage (secondary address space ALET=1).
ALET=2 gives access to storage in the home space. That's not needed for
this sample. But, if a PC routine calls another PC routine, you might
need ALET=2 to get at something in the original home space like the ASCB
or TCB. The PC routine can also acquire storage in its own address space
for answer areas and the like. (See ALET= and TCBADDR= parameters on the
STORAGE macro for details.)
The PC routines uses CDS (compare double-swap) to queue its request and
POSTs a server-provided ECB. Usually, it will then WAIT for a response
from th server, bit this is not always the case...
A TCB in the server address space wakes up (as a result of the POST),
pulls the request off the queue using CDS, and services the request
using all of the facilities available to ordinary programs running in
task mode under z/OS. When finished, it POSTs the ECB on which the
client is WAITing.
The PC routine wakes back up in the client address space, copies any
result data it might need back to its address space (ALET=1), frees the
storage (or returns it to the pool), and returns to its caller via the
PR instruction. It is now back in the client's mainline with
HASN=PASN=SASN.

Post by Jeffrey Barnard
If you can define what you need, write a requirement and present IBM with a
business case.

DB2 on z/OS is a big provider of space-switching, stacking PC services.
SQL clients (in CICS, batch, etc.) will use those PC services to access
DB2 objects. If you have CICS and DB2 running on z/VSE, some dumps might
help shed light on how this is being implemented in z/VSE.
And, if you can run under z/VM, TRACE is your friend...

[Tony Thigpen]

Like Martin, I played with PCs. It was back when they were first
introduced in VSE.

We had a SSPC that we wanted to use. There are a lot of limits in VSE.
As you mentioned, there is no LINKAGE=SYSTEM option on critical macros.
This limits SSPCs to the point that they are almost valueless.

At the time, and I don't think this has changed, there was no
'authorized' way to add new routines to the system PC list. We had to
add one by stuffing it into a 'reserved' slot.

We quit playing and wrote the code using supported VSE macros.

Since then, I have talked to development. Even talked about
LINKAGE=SYSTEM for a few key macros. They seem 'open' to 'maybe' doing
some enhancements in this area, but would need a vendor with a specific
requirement to request specific things. Since our code is stable, we no
longer have the requirement and so have not followed-up on getting
changes.

Tony Thigpen


-----Original Message -----
From: Jerry McCarthy
Sent: 07/11/2009 04:30 AM

Post by Jerry McCarthy
I have been experimenting with using program call's to implement a service
address space in VSE 3.1. Most of the macros to support this exist but as
far as I can tell there is only the zOS documentation and it doesn't always
apply. From what I can discern only non-system LX's are supported and you
can't specify SASN=OLD on an ETDEF. That and the fact that VSE macros don't
support linkage=system makes for an interesting challenge. I have been able
to create and use a program call in a single partition but when I attempt to
do an ETCON in another partition I get a Privileged operation exception even
though I am in supervisor state protect key zero. Can anybody point me in
the direction of any information or documentation that can further my goal
or is this not yet a possibility given the current state of VSE's cross
memory support.
Regards,
Jerry McCarthy
CPMG

[Chuck Arney]

Jerry, as Martin suggests XPCC is most likely the way to go in VSE.
Where we use SS-PCs in MVS code we have a different implementation in
VSE that uses XPCC instead. It takes a different design, and is not as
elegant of a solution IMO, but it does work when designed correctly and
it is a supported interface. Although I do wish XPCC allowed multiple
VSE tasks to communicate over an XPCC session, instead of being limited
to the single task that created the connection. That's something to
look out for when designing communication facilities with XPCC.

Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Internet-enable your applications with z/Ware V2
Voice: 214-800-8900 X#5562
--
This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed. If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or disseminating
this e-mail or any information contained in it.

We use reasonable measures to virus scan all E-mails leaving illustro
but no warranty is given that this E-mail and any attachments are virus
free. You should ensure you have adequate measures in place for your own
virus checking.

-----Original Message-----

Of

Jerry McCarthy
Sent: Saturday, July 11, 2009 3:27 AM
To: VSE Discussion List
Subject: Using Program Calls for Service Address Space
I have been experimenting with using program call's to implement a service
address space in VSE 3.1. Most of the macros to support this exist but as
far as I can tell there is only the zOS documentation and it doesn't always
apply. From what I can discern only non-system LX's are supported and you
can't specify SASN=OLD on an ETDEF. That and the fact that VSE macros don't
support linkage=system makes for an interesting challenge. I have

been

able
to create and use a program call in a single partition but when I

attempt

to
do an ETCON in another partition I get a Privileged operation

exception

even
though I am in supervisor state protect key zero. Can anybody point me in
the direction of any information or documentation that can further my goal
or is this not yet a possibility given the current state of VSE's cross
memory support.
Regards,
Jerry McCarthy
CPMG

[j***@cpmg.com]

Thanks everybody for your input. I already have an XPCC version of my
server running in zVSE. I am in the process of writing the zOS
version and am using SS-PCs in that environment. I was hoping that I
could convert my zVSE implementation to use SS-PC's to reduce the
amount of operating system dependent code. Sad to say zVSE does not
appear to be amenable to that hope at this time.

Regards,

Jerry McCarthy
CPMG

[JerryMc]

For anybody that is interested, a status update. I used the old
"SUBSID NOTIFY,NAME=CIC4" trick to "enable" my ETCON and now I have a
non-system space-switching PC routine that is accessible across
partitions. It looks like my dream may still be alive.

Regards,

Jerry McCarthy
CPMG

[Martin Truebner]

Jerry,

I used the old "SUBSID NOTIFY,NAME=CIC4" trick to "enable" my ETCON

Would useing PRODID&PRODEXIT yield the same results?

[JerryMc]

Post by Martin Truebner
Would useing PRODID&PRODEXIT yield the same results?
--
Martin
--

Hey Martin,

You are absolutely correct. Previously when I was issuing my MODESET
MODE=SUP I was getting a return code 4 (that I wasn't checking for in
my test program) because I had neglected to PRODID AUTH=YES prior.
Once I corrected the code to properly enter supervisor state the
SUBSID NOTIFY isn't necessary. The original Privileged operation
exception was due to a programming error on my part. Thanks for the
heads up.

Regards,

Jerry McCarthy
CPMG

[Martin Truebner]

Jerry,

Post by JerryMc
The original Privileged operation
exception was due to a programming error on my part.

now comes the time for a plug:

Are you aware that I give away a debugger for free?

That is on machine-code base it is free- the support for source-code
does cost money. But if you are like I am (I don't need a reference card
do disassemble code) this is more than enough.

[Steven W Huggins]

Hi Jerry,

I work on our BIM-ODIS product, in zVSE I use the LAM and SAC
instructions to navigate around
zVSE's address spaces to display and modify storage... It's a lot
better than the XPCC route, interested...?
The only thing you have to watch out for is fetch protected storage in
you CICS/TS partitions.
I touch the storage just to see if I get a program check, if I end up in
the STXIT PC, that thing I just touched
is fetch protected...

Steve Huggins, CSI

Post by j***@cpmg.com
Thanks everybody for your input. I already have an XPCC version of my
server running in zVSE. I am in the process of writing the zOS
version and am using SS-PCs in that environment. I was hoping that I
could convert my zVSE implementation to use SS-PC's to reduce the
amount of operating system dependent code. Sad to say zVSE does not
appear to be amenable to that hope at this time.
Regards,
Jerry McCarthy
CPMG

[Jeffrey Barnard]

I think a requirement may be in order here. The ability to define/delete
and use SSPC in z/VSE would be very, very useful.

As I see it we need
Define, Delete support
Also LINKAGE=SYSTEM for
GETVIS, FREEVIS
POST, WAIT
STXIT PC/AB?

What other z/VSE macros need LINKAGE=SYSTEM support?

Regards,
Jeff

[Chuck Arney]

That list would make me happy. As long as what you are calling Define,
Delete includes a System LX so that the SS-PC routine is available to
all partitions.

Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Internet-enable your applications with z/Ware V2
Voice: 214-800-8900 X#5562
--
This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed. If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or disseminating
this e-mail or any information contained in it.

We use reasonable measures to virus scan all E-mails leaving illustro
but no warranty is given that this E-mail and any attachments are virus
free. You should ensure you have adequate measures in place for your own
virus checking.

-----Original Message-----

Of

Jeffrey Barnard
Sent: Sunday, July 12, 2009 7:16 AM
To: VSE Discussion List
Subject: Re: Using Program Calls for Service Address Space
I think a requirement may be in order here. The ability to

define/delete

and use SSPC in z/VSE would be very, very useful.
As I see it we need
Define, Delete support
Also LINKAGE=SYSTEM for
GETVIS, FREEVIS
POST, WAIT
STXIT PC/AB?
What other z/VSE macros need LINKAGE=SYSTEM support?
Regards,
Jeff
--
Jeffrey C Barnard
Barnard Software, Inc. http://www.bsiopti.com
BSI 407-323-4773 Support 407-688-7123
No trees were killed in the creation of this message,
however several electrons were terribly inconvenienced.

[Martin Truebner]

Jeff,

XPOST and XWAIT would be nice in that list I guess (because I use it and
haven't fully explored PC environment- maybe my requirement would
disappear).

[JerryMc]

The ability to use SASN=OLD would be very useful.
Perhaps EXTRACT.

Regards,

Jerry McCarthy
CPMG

[Jeffrey Barnard]

I think SVC 107 fast reflect SVC's (GETFLD/MODFLD/TREADY) would be useful
and probably pretty easy to support (at least most of them).

Updated list

Define/Delete w/System LX

LINKAGE=SYSTEM for
Wait/Post
GETFLD/MODFLD/TREADY (SVC 107's)
STXIT PC/AB
GETVIS/FREEVIS

Did I miss anything.

Regards,
Jeff

[Martin Truebner]

Jeff,

(since we are in wish list mode)

come on- once 107 - all 107

I want VALID

and of course 120: XPOST

[Jeffrey Barnard]

Martin,

I am sorry, but why XPOST? You are already running in another address
space. OI ECB+2,X'80' and TREADY COND=IO,PART=(Rx)

Regards,
Jeff

[Edward Jaffe]

Post by Tony Thigpen
Martin,
I am sorry, but why XPOST? You are already running in another address
space. OI ECB+2,X'80' and TREADY COND=IO,PART=(Rx)

A PC routine is not "running" (dispatched) in another address space. It
is dispatched in its _own_ address space, with addressability to both
address spaces (ALET=0-server, ALET=1-client, ALET=2-home).

OI ECB+2,X'80' won't work to post a server task from a PC routine. The
turbo dispatcher can run work from multiple address spaces
simultaneously on different CPs.

[JerryMc]

Post by Edward Jaffe

Post by Tony Thigpen
Martin,

A PC routine is not "running" (dispatched) in another address space. It
is dispatched in its _own_ address space, with addressability to both
address spaces (ALET=0-server, ALET=1-client, ALET=2-home).
OI ECB+2,X'80' won't work to post a server task from a PC routine. The
turbo dispatcher can run work from multiple address spaces

Excuse me if I am incorrect in my understanding here but as long as
the ALET is set correctly all the OI ECB+2,X'80' does is turn on the
post bit. It's the TREADY COND=IO,TASK=(Rx) that drives the
dispatcher to wakeup the task to check the bit and dispatch the task.
If TREADY had LINKAGE=SYSTEM why wouldn't that work to post the server
task in this scenario? In my current explorations what I am doing is
after the PC routine returns having "deposited" the task request in a
preallocated server memory location (using a CDS type enqueue
mechanism) I have the client do the OI and the TREADY that drives the
server and that seems to work just fine (even though it requires that
the client run in supervisor state). Then after the the server task
completes the request it uses an ecb address, ELET and TID passed by
the client in the request to do a similar OI and TREADY to wakeup the
client.

Regards,

Jerry McCarthy
CPMG

[JerryMc]

Minor correction here. I obviously don't have a perfect grasp of
ALET, PS-AL, DU-AL intricacies. I originally passed the clients ALET
to the server, but got an exception when the server attempted to use
it to do the OI. I then passed the client PIK and did a GETFLD
FIELD=ALET,PART=CLIENTPIK on the server (getting a different ALET) and
that worked for the OI. I'm not sure why.

Also Jeff, when I said EXTRACT in terms of additrional requirements I
actually was thinking of GETFLD/MODFLD/TREADY (SVC 107's). More
confusion on my part.

Regards,

Jerry McCarthy
CPMG

[Martin Truebner]

Jerry,

Post by JerryMc
on the server (getting a different ALET) and
that worked for the OI. I'm not sure why.

I know why- I had the very same problem and publicy displayed my
confusion by posting here. Some good soul in the lab in Boeblingen made
a stmt about VSE only doing certain things if required.

Story is: the GETFLD FIELD=ALET... tickles VSE to create tables that are
required when accessing other address-spaces with ALETs.

[Ken Meyer]

I have not found anything I could not do using XPCC (in some cases)
and multiple address spaces (in others). As Huggy alluded to, there
are ways to control multiple partitions using address spaces and
TREADY or posting to an SVA field and using that as a basis for
performing some function. IBM could implement z/OS in z/VSE, but
then the costs for the customers would be at the z/OS levels.

Ken Meyer
CSI

[Chuck Arney]

Ken it is true that we can get the job done using XPCC but doing that,
there is a lot more work required in design, development and execution.
XPCC has its overhead and multi-tasking requirements/limitations. What
we are talking about is not implementing z/OS in VSE but rather getting
VSE to better utilize available hardware facilities than it currently
does. It certainly makes sense to implement the support the same way as
z/OS since it is a known and working interface, but VSE is free to
implement the usage of the hardware facility in anyway they choose.

SS-PC support is something we can live without, as we have been doing
for a very long time, but given a choice I'd rather not.


Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Internet-enable your applications with z/Ware V2
Voice: 214-800-8900 X#5562
--
This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed. If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or disseminating
this e-mail or any information contained in it.

We use reasonable measures to virus scan all E-mails leaving illustro
but no warranty is given that this E-mail and any attachments are virus
free. You should ensure you have adequate measures in place for your own
virus checking.

-----Original Message-----

Of

Ken Meyer
Sent: Monday, July 13, 2009 9:34 AM
To: VSE Discussion List
Subject: Re: Using Program Calls for Service Address Space
I have not found anything I could not do using XPCC (in some cases)
and multiple address spaces (in others). As Huggy alluded to, there
are ways to control multiple partitions using address spaces and
TREADY or posting to an SVA field and using that as a basis for
performing some function. IBM could implement z/OS in z/VSE, but
then the costs for the customers would be at the z/OS levels.

[Timothy Gregerson]

"Well put," Chuck. Tell Eric Tim says "Hi!"

Tim Gregerson

[Edward Jaffe]

Post by JerryMc

Post by Edward Jaffe
A PC routine is not "running" (dispatched) in another address space. It
is dispatched in its _own_ address space, with addressability to both
address spaces (ALET=3D0-server, ALET=3D1-client, ALET=3D2-home).
OI ECB+2,X'80' won't work to post a server task from a PC routine. The
turbo dispatcher can run work from multiple address spaces

Excuse me if I am incorrect in my understanding here but as long as
the ALET is set correctly all the OI ECB+2,X'80' does is turn on the
post bit.

Keep in mind, the OI instruction performs a fetch followed by a store as
observed by other CPs. If a unit of work running on another CP is
updating the same byte at exactly the same time, someone's intended
update will be lost. In general, you can't use OI for a byte that two
CPs might be updating.

The OI ECB+2 and TREADY technique works for ECBs because only one bit
(the 'traffic bit') is ever manipulated, service providers are coded to
always search their queues *after* resetting the traffic bit, and
service clients are coded to always put work on the queue *before*
posting the ECB. That way, even when an ECB update is lost, the request
gets serviced anyway. The worst thing that happens is sometimes a
service provider task wakes up an extra time to service an empty queue
and goes right back to sleep. No big deal.

[Steven W Huggins]

This is why it makes a lot of sense to clone you ECB's and place the
clone in the SVA...
Wait on the clone, and when posted, post the ECB in the Address Space
you are doing I/O in...

Just a thought on sharing storage nicely in zVSE...!!!

Steve Huggins, CSI

Post by Edward Jaffe

Post by JerryMc

Post by Edward Jaffe
A PC routine is not "running" (dispatched) in another address space. It
is dispatched in its _own_ address space, with addressability to both
address spaces (ALET=3D0-server, ALET=3D1-client, ALET=3D2-home).
OI ECB+2,X'80' won't work to post a server task from a PC routine. The
turbo dispatcher can run work from multiple address spaces

Excuse me if I am incorrect in my understanding here but as long as
the ALET is set correctly all the OI ECB+2,X'80' does is turn on the
post bit.

Keep in mind, the OI instruction performs a fetch followed by a store
as observed by other CPs. If a unit of work running on another CP is
updating the same byte at exactly the same time, someone's intended
update will be lost. In general, you can't use OI for a byte that two
CPs might be updating.
The OI ECB+2 and TREADY technique works for ECBs because only one bit
(the 'traffic bit') is ever manipulated, service providers are coded
to always search their queues *after* resetting the traffic bit, and
service clients are coded to always put work on the queue *before*
posting the ECB. That way, even when an ECB update is lost, the
request gets serviced anyway. The worst thing that happens is
sometimes a service provider task wakes up an extra time to service an
empty queue and goes right back to sleep. No big deal.