A gloating and deriding VM bigot proudly told me in 1977 that your code snippet would break MVT but not VM. But by then I was working with MVS, so I never tested it on an MVT sandbox, but I did test it on an MVS sandbox. I let the job run 100% CPU-bound for a couple of minutes, then canceled it with a dump. It took many minutes more of being CPU bound to generate the SYSUDUMP output, which contained hundreds of thousands of lines of output, almost all of which was the formatted RB chain. My MVS sandbox system did not crash, but I did not let this job run until "completion" either, so I don't know what would have happened on that primitive version of MVS. I believe, however, that your snippet would have caused my MVT sandbox, if I had tested it there, to crash, as explained next.
The first instruction, a BALR, puts the address of the next instruction, an SVC, into R15. The SVC 12 instruction, on any variant of OS/360 or its successors (PCP, MFT, MVT, SVS, VS1, VS2, MVS, ESA, S/390, z/OS, etc.) is the result of coding a SYNCH macro. The diagnostics book says that an SVC 12 causes a new RB to be chained off the current TCB and then control passes to the address in R15 with the newly built RB set up as the current RB. So these two instructions cause an infinite loop that builds RBs forever until there is no more available virtual storage with which to build the next RB. In MVS, RBs are built in LSQA, I believe, and when that resource is exhausted and more is needed, I believe that today's MVS, much more RAS-hardened than it was in 1977, will ABEND the current piece of work with an ABEND code reflecting that all requested CPU time had been used (an Sx22) and the system and all other work will keep running blissfully unaware of the virus Godzilla that almost swallowed Cleveland. MVT, however, built RBs with real storage, as MVT had no virtual storage. Real storage can be gobbled up much faster than virtual storage. And when MVT wanted to build the impossible next RB, it would crash rather than ABEND the current piece of work. I think. A clever sysprog, with luck and a lot of time spent looking at the standalone dump, could find out which program had crashed MVT, but he couldn't prevent this from happening again and again. It was intolerable that any normal user could run an unauthorized copy of your snippet and crash the whole system. Ignorance of such black holes in the system's design was what kept some MVTs up and running. Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, May 02, 2010 8:25 AM To: [email protected] Subject: Re: ZFS In <629a420612b49a4a96f9c143f22230781b01285...@mbx04.cgcent.miami.edu>, on 04/28/2010 at 07:37 PM, "Martinez, Frank J" <[email protected]> said: >MVT was not broken. 05F0 0A0C -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see <http://patriot.net/~shmuel/resume/brief.html> We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
