I never got to meet John Erhman but we corresponded a little. He was kind enough to get me included on the program at a Share conference in Anaheim. John wrote an excellent Assembler reference titled Assembler Language Programming for IBM z System Servers . Even a seasoned assembler programmer can learn a lot from this book – it’s packed with many interesting assembler goodies. I keep a link to it nearby and you should, too. I was browsing through it today and came across a suggestion he had for a program to write:
Programming Problem 41.3.(3)+ Write a program with a program interruption exit that generates each of the 15 possible interruption types in turn. For each interruption, generate a message describing the interruption type and the address of the interrupted instruction. Then, return to the mainline program to generate the next interruption.
The program suggestion comes after a section of the book that covers how to handle program interruptions using ESPIE. It wasn’t too hard to get a basic version of the program going. You do have to write some “bad” code to generate the 15 possible program interruptions. As I began to write this code, it struck me as funny that this would be the worst program ever. That’s when I thought it would be fun to enlist your help. Many of the interruptions are easy to generate – we’ve all sinned. But I did scratch my head on how to generate a S0C5. I can’t remember ever getting that interruption, but then my memory isn’t as good as it used to be.
Here’s how you can help: If you have a favorite way to generate one of the 15 possible program interrupts in just a few lines (the fewer the better) send it in. I’ll pick the ones I like best and include them in my program and give you credit. The program will appear in a future post or article on recovering from program interrupts. The program I’m writing does have an input file (FILEIN) and an output file (FILEOUT). That might help you with some of the interrupts. Be sure to include the definitions of any fields you need. As a small tribute to John, we’ll commit every possible error. Help me write the worst program ever!
Nice challenge! I’ll try to dig up what I can find from the archives of the Mainframe LinkedIn groups. I do remember a S0C5 is indeed very difficult to produce. I’ve never seen one:
http://linkedin.com/feed/update/urn:li:groupPost:1462937-5884391659344531458/ .
David Staudacher’s site is always worth a look. I recommend it to everyone. Thanks for the comment.
From the above link (for anyone who isn’t already a member of LinkedIn’s Mainframe Assembler Professionals group):
… the 0C5 abend is proving to be very elusive. I thought this might get it:
L 1,F’-1′
L 1,1(1,1)
… but no S0C5.
So, for the S0C5, that post actually isn’t very helpful. 🙁
Hi all punctilious ones,
When Don Higgins and I presented z390 at SHARE on many occasions, John Ehrman would chair our sessions
It was a great joy to me a few years ago when I posted a controversial request on the Assembler Forum. John contributed his 2-cents worth…yes John, I DO want all operands to have the full extent of the DC-type (although some disagreed)
John’s “Bible” was a brilliant piece of work and I was fortunate enough to be one of those chosen to review V1, and the result was V2 John kindly included me in the acknowledgments
Interruptions… In reality, only S0C1-S0CB are ‘regularly’ encountered S0CC-S0CF are floating point (FP) and very rare in commerce I would think it unfair for novice Assembler programmers to learn how to crash an FP instruction
Actually there are several hundred interrupt codes now going almost to X’FFF’…IBM…you’re going to need more bits
S0C5 is one of my pet hates, I get a lot of them An odd address will do it, mine are caused by a bad index into a branch table
David… I haven’t the time to enter this contest, but I am willing to review any submissions
The worst program ever… Oh no, this one doesn’t come anywhere near In my 55 years of Assembler debugging I’ve encountered code that still makes my hair stand on end (if I had any) JES exit that worked for years and then crashed MVS after every IPL My famous COBOL “PATCH ” bug that crashed CICS
To all… For those using z390, I am more than willing to act a mentor to those learning Assembler
Regards,
Melvyn Maltz.
Nice – I’ll give your branch table idea a try. I agree with you about the floating point errors for beginners.
0C6 is much more interesting because there are so many ways to get one (see z/Architecture Principles of Operations p 292 [Ch6 p32], here: http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr000.pdf ).
For instance, #4 “The PSW contains an odd instruction address”
Pretty easy. In the following (default AMODE 24), “BCTR 15,15” decrements R15 by 1 (thus creating an odd address, since R15 will contain the entry address, guaranteed to be even), then branches to that address. Boom! S0C6:
S0C6 CSECT
BCTR 15,15
END
Can’t get more succinct than that! I like it.
Many instructions also have restrictions which, if violated, generate a S0C6. For instance, MVCL requires even numbered register for both operands. In fact, HLASM won’t even 𝘭𝘦𝘵 you use an odd numbered register:
000000 0000 MVCL 1,0
** ASMA029E Incorrect register specification – 1
But, if you code the equivalent machine instruction yourself [MVCL = X’0E’]:
MVCL DC X’0E10′
You get nice S0C6!
S0C3 (Execute Exception) is likewise easy. Since this one only happens when an EX instruction targets another execute instruction, an EX which targets itself will suffice:
S0C6 CSECT
USING *,15
EX 0,*
Ack! I just noticed I didn’t change the CSECT name for the S0C3 example. CSECT should, of course, be S0C3,
The classic S0C1 (favorite of coders who just need to produce a dump at a precise program location) is, of course:
S0C1 CSECT
DC H’0′
END
0C1 is the ‘Invalid Op Code” interrupt, so coding an in-line constant of anything with a binary value that is not also a valid Op Code will suffice, e.g.
S0C1 CSECT
DC X’FF’
END
S0C2 (“Privileged Operation Exception”) can be had using just about any of the 370 instructions with the “p” attribute from the 370 Reference Summary: http://google.com/search?q=GX20-1850
such as “LPSW:
S0C2 CSECT
LPSW 0
END
S0C4 (Protection Exception) is a classic.
An old joke goes:
Instructor: “What is a S0C4?”
Student: “To keep your feet warm?”
Simply attempting to store something in low-core will do it:
S0C4 CSECT
ST 0,0
S0C4 (Protection Exception) is another classic.
An old joke goes:
Instructor: “What is a S0C4?”
Student: “To keep your feet warm?”
Simply attempting to store something in low-core will do it:
S0C4 CSECT
ST 0,0
Actually, for the S0C4 source, make that:
S0C4 CSECT
HOTSOCKS ST 0,0
Same machine code, better label! 😉
My one assembler joke:
A: What’s the difference between L and LA?
B: About a week of debugging.
Sadly, I’ve lived this joke.
One of the most cringeworthy pieces of code that I ever had the misfortune of encountering was a self-modifying wonder that allowed itself to be executed twice, but on the third (and any subsequent) entries, it would just return. Of course there were no comments or any documentation to describe what it was doing or why it was doing it.
It is impossible to get a s0C5 in problem state on z/OS because you are executing in virtual mode and the things that would cause a S0C5 are generally intercepted by the operating system as a page fault and either cause a page-in or are reflected to you using some other interrupt code. If you are authorized, you can execute in supervisor state, load a grande register with say X’FFFFFFFFFFFFFFF8′ (end of memory – 8) and use it a a real address (STURAG would do it). It is unlikely that you would have real memory at that address and a S0C5 should result…
Thanks, Peter!