A storage overlay cannot occur in a properly implemented PLO with a counter as long as the counter is properly maintained with every process incrementing it by 1. Even in in a free chain implementation, an improper PLO sequence can result in a circular or broken chain.
Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon Perryman Sent: Friday, November 08, 2013 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serialization without Enque This specific paragraph from Peter is about "FREE QUEUE PROTOCOL". This is where elements on your chain are no longer needed. Peter recommends not freeing the element. Instead, you should use a queue of free elements that you reuse when you need a new element. Peter's concern is not the chaining. It's with the data each element represents and making sure it remains consistent in a multi-processing environment. A program using the element is not guaranteed the element hasn't been freed and possibly re-allocated. PLO only ensures serialization of the chain. To ensure the element is valid, header validation is not a enough. You should maintain a validation field that is occasionally verified. This greatly reduces the exposure but does not completely eliminate it. Peter's concern is valid and justified. S0C4 abends are visible so they can be dealt with. The real problem is storage overlays that are not immediately apparent. Even worse is when they affect unrelated programs. Jon Perryman. >________________________________ > From: Donald Likens <dlik...@infosecinc.com> > > >Thank You for your help (all of you) but Peter's statement below does not make sense to me (maybe because I don't understand something). > >The reason that the free queue protocol needs a sequence number is >because even if the header "matches", the values that you need to put >into your new element for the "next" and/or "previous" may no longer be >correct due to a set of additional asynchronous operations. > >I use PLO to add an element to a chain. The chain only has forward pointers. I always add to the end of the chain. I use storage (not CPOOL) to get the element. It turns out that I haven't gotten the PLO instruction to work properly yet but in theory in my scenario it seem to me that if the pointer to the last element is pointing to a element (Not 0) I should be able to store the next pointer and the last pointer in one PLO CSDST. Here is the actual (not working code... It is not updating the chain properly): > >CSAMSEGL <== Last element on the chain >CSAMSEGF <== First element on the chain >R8 Address of element to add. >MSEGNEXT <== Pointer to next element in last control block MSEGCB <== >element name > >DOX078 DS 0H *C IF CSAMSEGL EQ 0 THEN (no elements on the >chain) > XR R4,R4 > XR R5,R5 > LR R2,R8 (R8: ADDRESS OF MSEGCB) > LR R3,R8 *C SET CSAMSEGL = CSAMSEGF = MSEGCB JUST >BUILT > CDS R4,R2,CSAMSEGF IF CSAMSEGF & CSAMSEGL = 0, STM >2,3,CSAMSEGF > BC 4,ELIFX076 *C ELSE > B EIFX076 >ELIFX076 DS 0H *C IF CSAMSEGL = CSAMSEGL (R2) *C SET CSAMSEGL = >POINTER_TO_NEW_MSEG (R8) *C SET MSEGNEXT = POINTER_TO_NEW_MSEG (R8) >CSDST EQU 16 > L R2,CSAMSEGL > LA R0,CSDST > LA R1,PLT > LR R3,R8 > LA R4,CSAMSEGL CSAMSEGL IS IN CSA > ST R4,OPERAND6 > LA R4,MSEGNEXT MSEGNEXT IS IN CSA > ST R4,OPERAND4 > ST R8,OPERAND3 > ST R8,OPERAND5 > PLO R2,CSAMSEGL,0,PL >* THE FIRST-OPERAND COMPARISON VALUE AND THE SECOND OPERAND ARE >* COMPARED. IF THEY ARE EQUAL, THE FIRST-OPERAND REPLACEMENT VALUE >* IS STORED AT THE SECOND-OPERAND LOCATION, AND THE THIRD OPERAND IS >* STORED AT THE FOURTHOPERAND LOCATION. THEN, THE FIFTH OPERAND IS >* STORED AT THE SIXTH-OPERAND LOCATION. > BNZ DOX078 >EIFX076 DS 0H > >PLT DS D PLO LOCK TOKEN PL DS 0F >PARAMETER LIST > ORG PL+60 >OPERAND3 DS A NEW MSEG ADDRESS > ORG PL+76 >OPERAND4 DS A ADDRESS OF CSAMSEGL > ORG PL+92 >OPERAND5 DS A NEW MSEG ADDRESS > ORG PL+108 >OPERAND6 DS A ADDRESS OF MSEGNEXT > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
