>From A22-6821-0 S/360 Principle of Operations: CONDITION CODE SETTINGS FOR FIXED-POINT ARITHMETIC x'00', x'01', x'10', x'11' 0 (equal) 1 (<0) 2 (>0) 3 (error, overflow)
Add H/F zero < zero > zero overflow Add Logical zero not zero zero, carry carry Compare H/F equal low high Load and Test zero < zero > zero Load Complement zero < zero > zero overflow Load Negative zero < zero Load Positive zero > zero overflow Shift Left Double zero < zero > zero overflow Shift Left Single zero < zero > zero overflow Shift Right Double zero < zero > zero Shift Right Single zero < zero > zero Subtract H/F zero < zero > zero overflow Subtract Logical not zero zero, carry carry On Thu, Feb 11, 2016 at 8:26 AM, Martin Packer <[email protected]> wrote: > Humour me and tell us all what setting the 4 bits in 15 means here. I had > actually looked at the green card on my home office wall (no really) and > figured the BCR 15,14 part out. > > Thanks, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, > Worldwide Cloud & Systems Performance, IBM > > +44-7802-245-584 > > email: [email protected] > > Twitter / Facebook IDs: MartinPacker > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > > > From: "Cannaerts, Jan" <[email protected]> > To: [email protected] > Date: 11/02/2016 14:17 > Subject: Re: AW: Re: You thought IEFBR14 was bad? Try GNU's > /bin/true code > Sent by: IBM Mainframe Discussion List <[email protected]> > > > > Considering IBM's practicing of OCO (if that was in place at the time of > that APAR's release?), why would IEFBR14 have needed an APAR to add > equates? Equates or no equates, the object code would have remained the > same; 1BFF 07FE. It's a source code thing only. > > The addition of setting the return code however, did add 2 bytes to the > object code, and thus would have warranted an APAR/PTF. > > Pedant that I am; the second instruction is, per the PoP, "BCR 15,14". BR, > BNZ, BZ, BNE, ... are shorthand for BCR with its different condition code > masks, but are not instructions themselves. > > Regards, > Jan > >>-----Original Message----- >>From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Mike Myers >>Sent: donderdag 11 februari 2016 2:12 >>To: [email protected] >>Subject: Re: AW: Re: You thought IEFBR14 was bad? Try GNU's /bin/true > code >> >>Robert and all: >> >>To set the record straight, I looked at the object code, which is: >>1BFF07FE, or >> SR 15,15 >> BR 14 >> >>I believe the second APAR was the addition of equates for R14 and R15 >>and to change the code to >> SR R15,R15 >> BR R14 >> >> because the former failed to meet programming standards. >> >>Mike Myers >>Mentor Services Corporation > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
