On Sun, 20 Jan 2008 11:09:57 -0800, Edward Jaffe wrote:

>Binyamin Dissen wrote:
>> In the past (370 pre PLO), CS was the only way to do this function.
>>
>> While it certainly is possible for IBM to rewrite WAIT/POST to use the PLO
>> instruction, I certainly doubt that such a code change will occur.
>
>Especially since PLO and CS do not serialize each other's updates!!
>
>> The code in the POPs is used - all over the place - to avoid an unnecessary
>> SVC/PC call. It is completely safe to use.
>
>Indeed. Used heavily by z/OS and nearly every z/OS-based ISV product
>I've ever seen.
>
I have believed, and other updates to this thread appear to concur,
that WAIT/POST are older than CS.  At some time, then, WAIT/POST
code must have used some other locking mechanism.  So, after CS
first became available there may have been some interval before it
was reliable to use CS to bypass POST.  When did that interim
conclude, making it safe to bypass POST in that fashion?  And might
there be open-source archival MVS (3.8 or earlier) that could
execute on emulated hardware supporting CS, but for which POST
requires the actual SVC?

And might IBM designers choose to convert to YA seriaization
technique in WAIT/POST (PLO?), rendering the customer and ISV use
of CS invalid?  I recognize this would be very difficult to do
in the existing marketplace, but it would transgress no commitment
in the absence of documentation stating that such use of CS is a
supported interface.  Remember the "provided".

I understand that during a WAIT, bits 1-31 of the ECB hold the
address of a control block.  If that control block resides above
the Line, might not its address spoof the POST bit?  I suppose
this is not a concern because no two tasks are allowed to WAIT
concurrently on the same ECB.

-- gil

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

Reply via email to