> :>The "quick post" approach of using CS to set the post bit of a not-waiting > :>ECB is a fully valid, documented approach. > > :>Of course it is extremely important to do it using the right key and to > :>have some reason to believe that the storage you are trying to update has > :>not been freed (and potentially re-obtained by a different job) > > :>This goes to why, in many cases, XM Post is not safe, as it is "POST by > :>ASID" and ASIDs can be reused, and, even within an ASID that is an > :>initiator, a job could end and another start. Since "POST by STOKEN with > :>TCBTOKEN" is not available, you need to do this yourself, unless you know > :>that the target ASID cannot terminate (hence its STOKEN cannot change) and > :>that it is not an initiator (such that the old job could end and a new job > :>could start). > > :>The proper protocol includes > :>-- capturing the ECB owner's STOKEN > :>-- capturing the ECB owner's TCBTOKEN (could be any task that is expected > :>to have the same persistence characteristics of the ECB, such as the > :>ASCBXTCB task when the job is running > :>-- scheduling an SRB with STOKEN to the poster's ASID, passing the TTOKEN > :>and the key to use > :>-- within the SRB: > :>-- obtaining the local lock > :>-- using the TCBTOKEN service to validate that the task is still OK > :>-- issuing branch-entry post > :>-- releasing the local lock > > Are you implying that one should open an APAR against XM POST as an integrity > exposure?
No. We are saying that XM POST requires that you serialize against termination of the target address space across the call to XM POST, and you serialize against the ECB storage being freed from the time that XM POST is called all the way to the asynchronous completion of the XM POST SRB. If, for example, you are XM POSTing an ECB which never gets freed in a non-memtermable address space, then these requirements are easily met. For more fluid cases, these requirements may be more difficult (or impossible) to meet. PAUSE/RELEASE is designed to avoid these kinds of issues. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
