On Wed, Jan 29, 2020 at 4:55 PM Charles Mills <[email protected]> wrote:
> In fact J <odd address> is impossible at assembly time, right? J *+10 > generates a jump instruction with an assembled offset of 5, right? That's > how they get +/- 65K into 16 bits. So J *+9 should generate an assembly > error. Even if you tried to code it yourself in hex, it's not possible. > Right? > My favorite for a one-instruction guaranteed abend (S0C1) is J *+2, which assembles as A7F40001. The *+2 is actually the "0001" inside the instruction. In a long ago flash back, I remember a discussion that branching to an area with an "opcode" of x'00' was greatly frowned upon becase, at the time, the "opcode" of x'00' was undefined but argued that IBM _might_ make it valid some time in the future. Apparently this coding was so prevelent that IBM actually changed the PoPS to say that x'00' would _never_ be a valid opcode. > > B <odd address>(0,r) and variants thereof are possible to create, but as > you say, they are S0C6's, not S0C5's. > > Charles > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of MELVYN MALTZ > Sent: Wednesday, January 29, 2020 2:17 PM > To: [email protected] > Subject: Re: Does S0C5 still exist ? > > No, that's a S0C6 > > ----- Original Message ----- > From: "John Melcher" <[email protected]> > To: <[email protected]> > Sent: Wednesday, January 29, 2020 9:33 PM > Subject: Re: Does S0C5 still exist ? > > > >J <odd address> doesn't do it? > > > > > > > > -----Original Message----- > > From: IBM Mainframe Assembler List <[email protected]> On > > Behalf Of Joe Dolcini > > Sent: Wednesday, January 29, 2020 3:32 PM > > To: [email protected] > > Subject: Re: Does S0C5 still exist ? > > > > *** External email: Verify sender before opening attachments or links *** > > > > > > I thought it was leftover from MVT (non-virtual) days. I found the > > following > > > > > > S0C5 – Addressing Exception > > > > Description > > An address developed and used by the ABENDing program lies outside of > the > > available virtual storage on the processor. > > > > Possible Causes > > > > Indexing, Subcripting outside the program’s assigned limits. > > Un-initialized index > > Attempt to read an unopened input file > > A missing or misspelled DD statement. > > An attempt to close a dataset second time An input/output instruction is > > terminated because an open is unable to complete Regarding the listed > > reasons that reference datasets, I didn’t think those would get an 0c5. > > > > > >> On Jan 29, 2020, at 3:23 PM, Steve Thompson <[email protected]> wrote: > >> > >> Get the PoOP and look at Program Interrupt Code (PIC) 5. > >> > >> I can't remember off the top of my head if this is addressing or > >> specification exception. > >> > >> Regards, > >> Steve Thompson > >> > >> On 1/29/20 4:11 PM, Melvyn Maltz wrote: > >>> As part of a training exercise I was challenged to write code that > >>> abended S0C5 While I'm very skilled at writing Assembler code that > >>> abends, I failed in this case :-( With the advent of much more secure > >>> storage allocation (if someone mentions CICS Storage Violations the > men > >>> in white coats will have to sedate me) is it possible to create a S0C5 > ? > >>> Some simple code that does it please > >>> Melvyn > > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown
