Yes, PIC 0002 existed, but a privileged S/370 instruction gave an 0001. If the program didn't get the appropriate PIC for the machine it was assembled for, it treated that as someone running a stolen or otherwise unauthorized copy.
The 0002 caused the code to go down the S/370 path when it had been assembled as authorized for use only on a S/360. The results were not pretty. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on behalf of Charles Mills <charl...@mcn.org> Sent: Thursday, January 30, 2020 3:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does S0C5 still exist ? 1. Didn't PIC 0002/S0C2 exist on a System 360? I seem to recall it but I could be wrong. I thought PIC 0002 that was part of the original architecture. 2. If he simulated System 370 instructions wasn't the environment effectively System 370, so your code was giving the right answer, effectively? Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, January 30, 2020 12:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does S0C5 still exist ? There's a reason that I never had a job as a typist. You're right, of course, that I meant S0C1. I used to use SPIE to distinguish between a S/360 and a S/370 by having the SPIE exit test whether a privileged instruction gave an 0001 or 0002; a friend had a PIH front end that simulated S/370 instructions and my code failed spectacularly. :-( -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on behalf of Keith Moe <ke...@sbcglobal.net> Sent: Thursday, January 30, 2020 3:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does S0C5 still exist ? S001 (from System Codes): An I/O error condition was encountered during BDAM, BISAM, BPAM, BSAM, QISAM, or QSAM processing. The completion code can be issued if CLOSE processing called end-of-volume (EOV), and EOV processing detected an out-of-space condition. See the explanation of message IEC020I in z/OS MVS System Messages, Vol 7 (IEB-IEE) for information about the task that was ended. S001 and S0C1 have nothing to do with each other. Keith Moe BMC Software On Thursday, January 30, 2020, 11:38:53 AM PST, Seymour J Metz <sme...@gmu.edu> wrote: Not quite; ABEND S001 indicates an operation exception that *WAS NOT HANDLED BY A SPIE OR SPIE EXIT*. Read my message again. I am prepared to defend what I wrote in this universe, not what I might have written in some alternate universe, and I never denied that a PIC 0001 was an operations exception. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on behalf of Dan Greiner <dan_grei...@att.net> Sent: Thursday, January 30, 2020 2:34 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does S0C5 still exist ? Hold the phone! See "z/OS MVS System Codes" (SA22-7626-25 ... dunno if this is the latest rev), page 106 or thereabouts. System completion code 0C1 (S0C1) indicates an operation exception (which, last time I checked the PoO, is most definitely a program interruption code 0001 [PIC-0001]. =
