Look at p. D-4 in the -0 edition. I don't know which, if either, to believe.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Joe Monk <joemon...@gmail.com> Sent: Wednesday, September 2, 2020 6:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Architectural Level Sets Page 7-31 says the only condition for XA is the "move-inverse facility" has to be installed... http://secure-web.cisco.com/1SPpJ14i6yPSxJtwCH2bDWOIflkX4XXef21JUr5kfopB5C45gj3ON-dCgd4dGxhf1LiqhJq3xDpG6edy1pkSDjADUZCx3k8nm1j708doaaRyYSrWRIxhsRKKI0NoftvS63fMKDK3BeaYN0r4H1BJU0R83NqonM4VyLjla0s83mCYtxGbfOkKvibAWAwGltnAFVkoohgCn9faPsGWv7Fv2QrMB4SW0DWHTwQ6vLrYYky2WBWk1kEsK3rGSZKU4QzdQVDdMophUz_Qn6upVCzVWm0fkAwLsKhpkyrp7NGWGJzQGzFZq99Bb54quRFmxiYIxqD9eUddjHK_hq491bNOYFYLKy9BTQjbYNAuPrxIi-D5nYaB7lgFyZtQadCIgDCsAI19vYpkARfQNUpdvrf3LMwwF7BCrzdi2EU_TGeF1YFabHw3hpKIyF7DmeoNvrTQu/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F370%2FprincOps%2FSA22-7085-1_370-XA_Principles_of_Operation_Jan87.pdf Joe On Wed, Sep 2, 2020 at 5:10 AM Seymour J Metz <sme...@gmu.edu> wrote: > Strange! The XA PoOps shows MVCIN as only available in S/370 mode. The > ESA PoOps shows it as Move-inverse facility, regardless of mode, and > ESA/390 PoOps shows it as standard. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Tony Thigpen <t...@vse2pdf.com> > Sent: Tuesday, September 1, 2020 10:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Architectural Level Sets > > And, to make matters worse, IBM reinstated the MVCIN on later processors > after having dropped it for at least one machine built after the 43xx > machines. It works now and has since at least the MP3k. > > Tony Thigpen > > Jesse 1 Robinson wrote on 9/1/20 9:36 PM: > > Instructions come and--believe it or not--instructions go. I once read > some doc on a newly introduced instruction. Don't remember the timeframe > or the exact instruction, but it came with this interesting comment. This > instruction, being new, will not cause a problem for existing code unless > that code expects the instruction *not* to exist. In that case the new > instruction will do something that the program does not expect. Right. One > sort-of case occurred in JES2, whose error handling for 3900 printers had > become increasingly convoluted to the point that the simplest short term > 'fix' was to force a S0C1 abend and let JES2 internal error routines > perform recovery using built-in code. This was accomplished by deliberately > branching to an invalid 'instruction'. JES2 would clean up the printer and > move on. Unfortunately, the APAR delivering this change branched to > character data that looked like a packed decimal instruction. So instead of > S0C1, the resulting S0C7 caused a JES2 abend. Not at all what was intended. > > > > As for a vanishing instruction, I once wrote some code using the Move > Inverse (MVCIN) instruction, which greatly simplified scanning data for a > terminating character. Apparently MVCIN was introduced on the 4341 (?) but > not carried forward to subsequent models. So S0C1. A rude shock for a > clever programmer looking for ingenious solutions. > > > > > > > > > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Seymour J Metz > > Sent: Tuesday, September 1, 2020 5:27 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Architectural Level Sets > > > > CAUTION EXTERNAL EMAIL > > > > Well, a S/360 program that depends on getting PIC 06 for an unaligned > load won't work correctly on a 360/85 or S/370. S/370 supported 2 KiB > pages, and those are history. MVS/370 uses SIO, whch only exists in S/370 > mode: also history. So carrying an old OS forward has always has issues. > Sure, IBM could ensure absolute compatibiity for old releaes, but > TANSTAAFL. Only IBM knows what the extra cost would be, but I guaranty that > there would be an extra cost. > > > > I'm sure that this has been discussed at Share. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > ________________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Tony Thigpen <t...@vse2pdf.com> > > Sent: Tuesday, September 1, 2020 5:20 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Architectural Level Sets > > > > I was thinking more along the lines of things that prevented earlier > operating systems from even IPLing on newer boxes. Such as z13 is the last > processor to have ESA/390 mode. I also have it in my head that at some > point there were changes to the page size and virtual storage tables that > caused havoc. > > > > Tony Thigpen > > > > Seymour J Metz wrote on 9/1/20 3:30 PM: > >> Typically the new features reqiured by a level set were added over > several generations, and each generation added more than one feature. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> http://mason.gmu.edu/~smetz3 > >> > >> > >> ________________________________________ > >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > >> behalf of Tony Thigpen <t...@vse2pdf.com> > >> Sent: Tuesday, September 1, 2020 3:25 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Architectural Level Sets > >> > >> IBM has had several Architectural Level Set points where there were > >> significant changes to the CPU that prevented earlier operating > >> systems from running on them. > >> > >> What CPU's were involved with each level, and what was the real > >> underlying item changed on the CPU that forced a new level? (Let's > >> keep it limited to z990 and newer.) > >> > >> > >> Tony Thigpen > >> > >> ---------------------------------------------------------------------- > >> 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 > > > > ---------------------------------------------------------------------- > > 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 > > > ---------------------------------------------------------------------- > 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
