That is an interesting observation. And, like you, makes me really wonder "why bother?". You mention testing for zero, but any address validity methodology is suspect when you can get an S0C4 (like PIC 11) if the actual address is invalid. Much safer to do the test/branch/modify.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Thomas David Rivers > Sent: Tuesday, November 27, 2012 10:19 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Usefullness (or not) of STOC/LOC instructions? > > We've been using the STOC/LOC (STORE/LOAD ON CONDITION) instructions > for some time... > > But, we just noticed a few words in the Principles of Operations (I'm > quoting from the STOC discussion): > > When the condition specified by the M3 field is not met (that is, > store operation is not performed), it is model dependent whether > any or all of the following occur for the second operand: (a) an > access exception is recognized, (b) a PER storage-alteration event > is recognized, (c) a PER zero-address-detection event is > recognized, > or (d) the change bit is set. > > Now - a rather common programming idiom is to store a result if a > pointer is not NULL. So, it would seem that a comparision of a pointer > to x'0' > followed by > a STOC would be a nice programming idiom. > > However, one of our recent tests (on a zPDT platform) blows up with > this > paradigm... getting an 0C4. Even though the condition in the STOC is > not > met and the store will not occur... > > The Principles of Operation also appear to be inconsistent, it makes > this claim: > > For example, the following two instruction sequences are > equivalent. > > STOCG 15,256(7),8 BC 7,SKIP > STG > 15,256(0,7) > SKIP DS 0H > > But, according to the paragraph quoted above, the two sequences are not > equivalent. The sequence on the right might not have the possibility > of generating an access-exception, while the STOCG does have that > possibility even though the store would not occur. > > I find these semantics a little baffling and wonder if that doesn't > essentially make STOC/LOC pretty much unusable in all but the most > restrictive situations? > > Thoughts/Opinions??? > > > - Dave Rivers - > > -- > riv...@dignus.com Work: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > ---------------------------------------------------------------------- > 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
