I'm guessing that Peter was warning against the situation where you have an 
element table rather than a queue. Queues are straight forward because each 
entry will only be in use by 1 program at any given time (ownership is always 
the task using it). Element tables on the other hand may have multiple tasks 
referencing the same entry at the same time. An example that is easily 
understood is dynamic LPA. These modules exist in common storage and you may 
dynamically replace them with a new version. Anyone still using the old version 
must not abend so IBM leaves all old versions in storage until the next IPL. 
Since you don't know if anyone is using the old version, you can't free / reuse 
it. In the old days when CSA was constrained, it was a real problem to use such 
commands. Today, we don't think twice about it but it still eats up some CSA.

As for handling a queue, I use  CS with the entries LIFO on the queue. A common 
task removes the queued entries and takes ownership.  At that time, it repairs 
the forward pointers and gets the first entry. I haven't heard anything here 
that would make me think that PLO would be less expensive so I wouldn't bother 
changing it's implementation

Jon Perryman.



>________________________________
> From: Kenneth Wilkerson <[email protected]>
>
>
>
>Yes, I was talking about all references using PLO. I was also assuming this
>was a "work" queue where "deletion" from the chain was the methodology for
>claiming ownership of the element. 
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to