Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
On 2020-08-10 02:13, Seymour J Metz wrote: I'm fully conversant with UNPK, Obviously you are not, or you would not have said that the ASCII bit "only affects the handling of the sign nybble". including the fact that the zone it sets depends on the value of the ASCII bit. How is that relevant to handling teletypes? Um, if an UNPK'd number is sent to an ASCII TTY then it must have the proper ASCII zone. (Other characters sent to an ASCII TTY would need to be in ASCII also.) Shmuel (Seymour J.) Metz From: IBM Mainframe Assembler List on behalf of robi...@dodo.com.au Sent: Sunday, August 9, 2020 10:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) On 2020-08-09 15:05, Seymour J Metz wrote: How is the ASCII bit relevant to teletypes? It only affects the handling of the sign nybble. You might want to check out the UNPK instruction. Shmuel (Seymour J.) Metz From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Saturday, August 8, 2020 11:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) - Original Message - From: "Steve Smith" To: Sent: Sunday, August 09, 2020 10:57 AM Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) The ASCII feature of S/360 probably wasn't used because it's nearly useless. What? See my earlier report that no IBM operating system could turn on the ASCII bit. The ASCII feature would have been useful in talking to ASCII teletypes. Turning on ASCII mode caused PACK & CVD to generate ASCII sign codes and UNPK to generate ASCII zone codes. As far as I can tell, that's it. I'd say that the much later PKA & UNPKA instructions make a lot more sense than a system option, so I suppose somebody thinks the function is useful. But you could always convert zoned decimal with NC/OC or, of course TR. ED isn't in my very old S/360 PoOp (A22-6821-0), no? Look at page 57. ED, EDMK, TR, TRT, etc etc are all in this manual. See Bitsavers. but ED certainly came out soon, long before the ASCII bit was officially dropped. Anyway, I don't know whether it supported ASCII mode or not. It did. Both EBCDIC and ASCII. But, as I reported earlier, no IBM operating system permitted the ASCII bit to be set.
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
I'm fully conversant with UNPK, including the fact that the zone it sets depends on the value of the ASCII bit. How is that relevant to handling teletypes? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of robi...@dodo.com.au Sent: Sunday, August 9, 2020 10:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) On 2020-08-09 15:05, Seymour J Metz wrote: > How is the ASCII bit relevant to teletypes? It only affects the > handling of the sign nybble. You might want to check out the UNPK instruction. > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Assembler List > on behalf of Robin Vowels > Sent: Saturday, August 8, 2020 11:40 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) > > - Original Message - > From: "Steve Smith" > To: > Sent: Sunday, August 09, 2020 10:57 AM > Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) > > >> The ASCII feature of S/360 probably wasn't used because it's nearly >> useless. > > What? See my earlier report that no IBM operating system could > turn on the ASCII bit. > > The ASCII feature would have been useful in talking to ASCII teletypes. > >> Turning on ASCII mode caused PACK & CVD to generate ASCII sign >> codes and UNPK to generate ASCII zone codes. As far as I can tell, >> that's >> it. I'd say that the much later PKA & UNPKA instructions make a lot >> more >> sense than a system option, so I suppose somebody thinks the function >> is >> useful. But you could always convert zoned decimal with NC/OC or, of >> course TR. >> >> ED isn't in my very old S/360 PoOp (A22-6821-0), > > no? Look at page 57. > > ED, EDMK, TR, TRT, etc etc are all in this manual. See Bitsavers. > >> but ED certainly came out >> soon, long before the ASCII bit was officially dropped. Anyway, I >> don't >> know whether it supported ASCII mode or not. > > It did. Both EBCDIC and ASCII. > > But, as I reported earlier, no IBM operating system permitted the > ASCII bit to be set.
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
On 2020-08-09 15:05, Seymour J Metz wrote: How is the ASCII bit relevant to teletypes? It only affects the handling of the sign nybble. You might want to check out the UNPK instruction. Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Saturday, August 8, 2020 11:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) - Original Message - From: "Steve Smith" To: Sent: Sunday, August 09, 2020 10:57 AM Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) The ASCII feature of S/360 probably wasn't used because it's nearly useless. What? See my earlier report that no IBM operating system could turn on the ASCII bit. The ASCII feature would have been useful in talking to ASCII teletypes. Turning on ASCII mode caused PACK & CVD to generate ASCII sign codes and UNPK to generate ASCII zone codes. As far as I can tell, that's it. I'd say that the much later PKA & UNPKA instructions make a lot more sense than a system option, so I suppose somebody thinks the function is useful. But you could always convert zoned decimal with NC/OC or, of course TR. ED isn't in my very old S/360 PoOp (A22-6821-0), no? Look at page 57. ED, EDMK, TR, TRT, etc etc are all in this manual. See Bitsavers. but ED certainly came out soon, long before the ASCII bit was officially dropped. Anyway, I don't know whether it supported ASCII mode or not. It did. Both EBCDIC and ASCII. But, as I reported earlier, no IBM operating system permitted the ASCII bit to be set.
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
Are you talking about 5740-XT2 (V1) or 5740-XT8 (V2)? Was it part of a standard install or optional? Did the documentation warn that installing the SVC would breach integrity? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Leland Bond <0d7433ac18a9-dmarc-requ...@listserv.uga.edu> Sent: Sunday, August 9, 2020 2:52 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) The source for the ISPF/PDF SVC allowing it to run IEBCOPY was published by IBM and used in many (most?) shops. It was trivial to circumvent the checks that supposedly ensured it was being used for its intended purpose. The best that could be said about the checks was that they made it difficult to accidentally invoke the SVC. Even if that SVC wasn’t installed, it was easy to write a scanner to find similar backdoor SVCs and PCs installed by extremely popular ISV software or written by supposedly-knowledgeable systems programmers. Such backdoors with minimal to no validation were installed on all systems I saw well into the 1990’s, which was when I stopped looking. One of the best uses of such a backdoor was to turn on the bit in the ACEE that gave your TSO session RACF special or operations authority until the session was logged off or the bit was turned off using the same technique. It came in handy at one place I worked where I often had to submit a form and wait up to a week to do something required by my job - all because management felt “Process" was far more important than results. Those of you who know my dislike of the “P” word will know the company. This should also a lesson for those who write security products: Don’t base all protection on a single bit in user-addressable memory. David Bond > On 9 Aug 2020, at 07:26, Seymour J Metz wrote: > > No. I remember shops that had one or more such SVCs, but they weren't part of > the MVS code base. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Assembler List on > behalf of Robert Netzlof > Sent: Saturday, August 8, 2020 1:20 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) > > But do remember that in Ye Gude Auld Days, there was a widely known > "magic" SVC which granted authorization to the user. > > On 8/8/20, Doug Wegscheid wrote: >> Site-specific SVC to do so? >> >>On Saturday, August 8, 2020, 12:11:14 PM EDT, >> wrote: >> >> Interesting are the two paragraphs on page 302, bottom RHS. >> >> Case says that nobody used the ASCII capability of the S/360. >> >> Padegs says that "none of our operating systems were [sic] programmed >> to turn in the [ASCII] bit". >> >> So, no-one was able to use the ASCII facility. >> >> On 2020-08-08 12:19, Jim Mulder wrote: >>> https://secure-web.cisco.com/1aUqvwFSpDRbVn1aNs20guYdvXOPJuuZo5gtacL9Gf9EkZxszA21zIT61i9R8WB_j6gx90NmLvIxo3RSZADv4WZ3_gAGC2hsKqPLrZVSMAnqd1ULXDJ_N1Q0jTv6Py9O8j81_ZaN9_2QMJidYBlRdBbVmWK5O8Ok5dZvJE5VcdhWpmPgsG4lqNkpIOeeau3Hj_Mz29Pj3HE1LN_9KhlrMZlmK2tJGa8Bdh6ca81ZFRgj0foFG9Z5oBRb45u3ITmHFU4F9AbzKRB5tZWb294HsZdywlGOGfo70KzhWg_JKhm7kFz1_2z8NdtTe_kHlsEBKgmbTqz059j1ekDC0Mf-UZ-o2FEaXuQN7gmYaMBSZymqfxf0dAjCFAJVJlxDllnLswiB3PZCp11aX82cgk2xB5NYqTQwKnwiw_pzVyi9po6OCPHbc5BlgAaKecpPV0izK/https%3A%2F%2Fwww.cs.tufts.edu%2Fcomp%2F150FP%2Farchive%2Falfred-spector%2Fspector87ibm.pdf >>> >>> >>> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >>> Poughkeepsie NY >> >> > > > -- > Bob Netzlof a/k/a Sweet Old Bob >
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
My discussion was about the architecture. The fact that it wasn't supported by the OSes of the day may be true, but that doesn't mean it was "prevented", or *couldn't* be used. If customers thought it was useful, they could have asked IBM to support it, or implemented it themselves. The salient fact, according to the article, is that no one ever did. I'm aware that -0 means first edition in IBM manual numbering, but they occasionally change the manual number and start over. Anyway, it appeared to be the oldest one on bitsavers, which is where I got it. sas
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
The source for the ISPF/PDF SVC allowing it to run IEBCOPY was published by IBM and used in many (most?) shops. It was trivial to circumvent the checks that supposedly ensured it was being used for its intended purpose. The best that could be said about the checks was that they made it difficult to accidentally invoke the SVC. Even if that SVC wasn’t installed, it was easy to write a scanner to find similar backdoor SVCs and PCs installed by extremely popular ISV software or written by supposedly-knowledgeable systems programmers. Such backdoors with minimal to no validation were installed on all systems I saw well into the 1990’s, which was when I stopped looking. One of the best uses of such a backdoor was to turn on the bit in the ACEE that gave your TSO session RACF special or operations authority until the session was logged off or the bit was turned off using the same technique. It came in handy at one place I worked where I often had to submit a form and wait up to a week to do something required by my job - all because management felt “Process" was far more important than results. Those of you who know my dislike of the “P” word will know the company. This should also a lesson for those who write security products: Don’t base all protection on a single bit in user-addressable memory. David Bond > On 9 Aug 2020, at 07:26, Seymour J Metz wrote: > > No. I remember shops that had one or more such SVCs, but they weren't part of > the MVS code base. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Assembler List on > behalf of Robert Netzlof > Sent: Saturday, August 8, 2020 1:20 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) > > But do remember that in Ye Gude Auld Days, there was a widely known > "magic" SVC which granted authorization to the user. > > On 8/8/20, Doug Wegscheid wrote: >> Site-specific SVC to do so? >> >>On Saturday, August 8, 2020, 12:11:14 PM EDT, >> wrote: >> >> Interesting are the two paragraphs on page 302, bottom RHS. >> >> Case says that nobody used the ASCII capability of the S/360. >> >> Padegs says that "none of our operating systems were [sic] programmed >> to turn in the [ASCII] bit". >> >> So, no-one was able to use the ASCII facility. >> >> On 2020-08-08 12:19, Jim Mulder wrote: >>> https://secure-web.cisco.com/1aUqvwFSpDRbVn1aNs20guYdvXOPJuuZo5gtacL9Gf9EkZxszA21zIT61i9R8WB_j6gx90NmLvIxo3RSZADv4WZ3_gAGC2hsKqPLrZVSMAnqd1ULXDJ_N1Q0jTv6Py9O8j81_ZaN9_2QMJidYBlRdBbVmWK5O8Ok5dZvJE5VcdhWpmPgsG4lqNkpIOeeau3Hj_Mz29Pj3HE1LN_9KhlrMZlmK2tJGa8Bdh6ca81ZFRgj0foFG9Z5oBRb45u3ITmHFU4F9AbzKRB5tZWb294HsZdywlGOGfo70KzhWg_JKhm7kFz1_2z8NdtTe_kHlsEBKgmbTqz059j1ekDC0Mf-UZ-o2FEaXuQN7gmYaMBSZymqfxf0dAjCFAJVJlxDllnLswiB3PZCp11aX82cgk2xB5NYqTQwKnwiw_pzVyi9po6OCPHbc5BlgAaKecpPV0izK/https%3A%2F%2Fwww.cs.tufts.edu%2Fcomp%2F150FP%2Farchive%2Falfred-spector%2Fspector87ibm.pdf >>> >>> >>> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >>> Poughkeepsie NY >> >> > > > -- > Bob Netzlof a/k/a Sweet Old Bob >
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
No. I remember shops that had one or more such SVCs, but they weren't part of the MVS code base. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robert Netzlof Sent: Saturday, August 8, 2020 1:20 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) But do remember that in Ye Gude Auld Days, there was a widely known "magic" SVC which granted authorization to the user. On 8/8/20, Doug Wegscheid wrote: > Site-specific SVC to do so? > > On Saturday, August 8, 2020, 12:11:14 PM EDT, > wrote: > > Interesting are the two paragraphs on page 302, bottom RHS. > > Case says that nobody used the ASCII capability of the S/360. > > Padegs says that "none of our operating systems were [sic] programmed > to turn in the [ASCII] bit". > > So, no-one was able to use the ASCII facility. > > On 2020-08-08 12:19, Jim Mulder wrote: >> https://secure-web.cisco.com/1aUqvwFSpDRbVn1aNs20guYdvXOPJuuZo5gtacL9Gf9EkZxszA21zIT61i9R8WB_j6gx90NmLvIxo3RSZADv4WZ3_gAGC2hsKqPLrZVSMAnqd1ULXDJ_N1Q0jTv6Py9O8j81_ZaN9_2QMJidYBlRdBbVmWK5O8Ok5dZvJE5VcdhWpmPgsG4lqNkpIOeeau3Hj_Mz29Pj3HE1LN_9KhlrMZlmK2tJGa8Bdh6ca81ZFRgj0foFG9Z5oBRb45u3ITmHFU4F9AbzKRB5tZWb294HsZdywlGOGfo70KzhWg_JKhm7kFz1_2z8NdtTe_kHlsEBKgmbTqz059j1ekDC0Mf-UZ-o2FEaXuQN7gmYaMBSZymqfxf0dAjCFAJVJlxDllnLswiB3PZCp11aX82cgk2xB5NYqTQwKnwiw_pzVyi9po6OCPHbc5BlgAaKecpPV0izK/https%3A%2F%2Fwww.cs.tufts.edu%2Fcomp%2F150FP%2Farchive%2Falfred-spector%2Fspector87ibm.pdf >> >> >> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >> Poughkeepsie NY > > -- Bob Netzlof a/k/a Sweet Old Bob
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
If you're referring to OS/360, even MVT was a Swiss cheese. As for MVS, there were certainly installations that shot themselves in the foot, but I doubt that there were ever half a dozen known integrity exposures in IBM's code at the same time. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Saturday, August 8, 2020 5:19 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) Or a dozen or more other non-magic ways of getting into supervisor state. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert Netzlof Sent: Saturday, August 8, 2020 10:20 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) But do remember that in Ye Gude Auld Days, there was a widely known "magic" SVC which granted authorization to the user. On 8/8/20, Doug Wegscheid wrote: > Site-specific SVC to do so? > > On Saturday, August 8, 2020, 12:11:14 PM EDT, > wrote: > > Interesting are the two paragraphs on page 302, bottom RHS. > > Case says that nobody used the ASCII capability of the S/360. > > Padegs says that "none of our operating systems were [sic] programmed > to turn in the [ASCII] bit". > > So, no-one was able to use the ASCII facility. > > On 2020-08-08 12:19, Jim Mulder wrote: >> https://secure-web.cisco.com/1BEZXLLirhr8iVyJvinGMvcSSpuLxffS5lC_0gurza2yeQqqXl1Cu5iKvKontNtxdgL_bJ3KDzCPUqy4K6JztHf8b5TtpbrwtxSBPohVfBXHavDinuDdmlvt4o27CsOqBZcNO1Zzl8Nj28qZAfs9QOW8uJ00o2t14uc_o9qJw48qJjcghhsJ4O_LCILmS0Eu6T8HITDvnE0QTWvYdSx_n43XkZbHbYbDjKAkrdpkj_O3MJoU9ltU2szVIUbOles3o5inhIRSrPpYQqp8e2NjslRtJWzMutBj8jF4RzqWTWWr3JruB9gTniVtvb--mNZ9v7FBIcAiNVMFzrsx3qxglkMStx9ST1nfobJyXeH982F98OtIxb7EwDhz9_HvoshLCbeccucIg2mmLTLfm5XRNwNsCQTuMQfRx2NOZNGkByethG6fEuX3a0uXVuGEwMO7M/https%3A%2F%2Fwww.cs.tufts.edu%2Fcomp%2F150FP%2Farchive%2Falfred-spector%2Fspector87ibm.pdf >> >> >> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >> Poughkeepsie NY > > -- Bob Netzlof a/k/a Sweet Old Bob
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
MVS can not run on any machine that had an ASCII bit in the PSW. There was no statement of integrity for OS/360. Does anybody know whether there was a statement of integrity for RSS/360? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Saturday, August 8, 2020 7:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) I am not suggesting anything nefarious or in violation of the Statement. A program that is linkedited (sorry, I just can't get used to saying "bound") with AC=1 and stored into an APF-authorized library -- all documented and above-board and under the customer's control -- can issue MODESET MODE=SUP and get into supervisor state. In addition, various "user" exits run in supervisor state. As do appendage routines IIRC. Etc. APF-authorized products may have PC routines that run in supervisor state. The point of my post was not "oh, z/OS is full of holes." It's not AFAIK, and I did not mean anything of the sort. My point was that there might have been code somewhere that set the ASCII bit on, even if the IBM OSes did not offer a "MODESET SIGN=ASCII" macro instruction. There are several ways that customer or vendor code may have done so in addition to "magic SVCs." And yes, before someone else points it out, my memory of the history of the platform is not perfect. Exactly which of these methods were available back when the ASCII bit was still around is not something that is at the top of my stack. Certainly magic SVCs were less out of fashion back in those days. I would have to think this through, but right off it would seem to me that a semi-magical SVC that did only one thing -- toggling the ASCII bit for its caller -- would not violate the integrity of the box as a whole. There could be some factor I have not thought of; this is an off-hand speculation of moot significance, not a statement to give to your auditor. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, August 8, 2020 2:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) On 2020-08-08, at 15:19:05, Charles Mills wrote: > > Or a dozen or more other non-magic ways of getting into supervisor state. > How does this interact with IBM's Statement of Integrity: https://www.vm.ibm.com/devpages/SPERA/istatmnt.html ... IBM will accept all APARs that describe exposures to the System Integrity of MVS ... System Integrity is defined for MVS as the inability of any program not authorized by a mechanism under the customer's control to: • circumvent or disable store or fetch protection • access an OS password-protected or a RACF-protected resource (RACF is the Resource Access Control Facility), or • obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. Of course, "under the customer's control" is a key phrase.
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
How is the ASCII bit relevant to teletypes? It only affects the handling of the sign nybble. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Saturday, August 8, 2020 11:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) - Original Message - From: "Steve Smith" To: Sent: Sunday, August 09, 2020 10:57 AM Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) > The ASCII feature of S/360 probably wasn't used because it's nearly > useless. What? See my earlier report that no IBM operating system could turn on the ASCII bit. The ASCII feature would have been useful in talking to ASCII teletypes. > Turning on ASCII mode caused PACK & CVD to generate ASCII sign > codes and UNPK to generate ASCII zone codes. As far as I can tell, that's > it. I'd say that the much later PKA & UNPKA instructions make a lot more > sense than a system option, so I suppose somebody thinks the function is > useful. But you could always convert zoned decimal with NC/OC or, of > course TR. > > ED isn't in my very old S/360 PoOp (A22-6821-0), no? Look at page 57. ED, EDMK, TR, TRT, etc etc are all in this manual. See Bitsavers. > but ED certainly came out > soon, long before the ASCII bit was officially dropped. Anyway, I don't > know whether it supported ASCII mode or not. It did. Both EBCDIC and ASCII. But, as I reported earlier, no IBM operating system permitted the ASCII bit to be set. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
- Original Message - From: "Steve Smith" To: Sent: Sunday, August 09, 2020 12:23 PM Sheesh... I missed it somehow, but it is in there. ED & EDMK did support ASCII mode, and used x'3x' zones in that case. This old, possibly original The "-0" version of IBM manuals is always the first (original) edition. (it has no date), Principles of Operation was a whopping 168 pages. But I haven't read the whole thing :-). ED & EDMK are listed in the "Logical Operations" section, whereas PACK & UNPK are in the "Decimal Arithmetic" section. You know which pair can cause a S0C7 though. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
- Original Message - From: "Charles Mills" To: Sent: Sunday, August 09, 2020 11:29 AM ED was not part of the original S/360 instruction set? Did you look under Decimal Instructions? It isn';t under "Decimal Instructions". Try the chapter, Logical Instructions. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
- Original Message - From: "Steve Smith" To: Sent: Sunday, August 09, 2020 10:57 AM Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) The ASCII feature of S/360 probably wasn't used because it's nearly useless. What? See my earlier report that no IBM operating system could turn on the ASCII bit. The ASCII feature would have been useful in talking to ASCII teletypes. Turning on ASCII mode caused PACK & CVD to generate ASCII sign codes and UNPK to generate ASCII zone codes. As far as I can tell, that's it. I'd say that the much later PKA & UNPKA instructions make a lot more sense than a system option, so I suppose somebody thinks the function is useful. But you could always convert zoned decimal with NC/OC or, of course TR. ED isn't in my very old S/360 PoOp (A22-6821-0), no? Look at page 57. ED, EDMK, TR, TRT, etc etc are all in this manual. See Bitsavers. but ED certainly came out soon, long before the ASCII bit was officially dropped. Anyway, I don't know whether it supported ASCII mode or not. It did. Both EBCDIC and ASCII. But, as I reported earlier, no IBM operating system permitted the ASCII bit to be set. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
Sheesh... I missed it somehow, but it is in there. ED & EDMK did support ASCII mode, and used x'3x' zones in that case. This old, possibly original (it has no date), Principles of Operation was a whopping 168 pages. But I haven't read the whole thing :-). ED & EDMK are listed in the "Logical Operations" section, whereas PACK & UNPK are in the "Decimal Arithmetic" section. You know which pair can cause a S0C7 though. sas On Sat, Aug 8, 2020 at 9:29 PM Charles Mills wrote: > ED was not part of the original S/360 instruction set? Did you look under > Decimal Instructions? > > Charles > >
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
ED was not part of the original S/360 instruction set? Did you look under Decimal Instructions? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Saturday, August 8, 2020 5:57 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) The ASCII feature of S/360 probably wasn't used because it's nearly useless. Turning on ASCII mode caused PACK & CVD to generate ASCII sign codes and UNPK to generate ASCII zone codes. As far as I can tell, that's it. I'd say that the much later PKA & UNPKA instructions make a lot more sense than a system option, so I suppose somebody thinks the function is useful. But you could always convert zoned decimal with NC/OC or, of course TR. ED isn't in my very old S/360 PoOp (A22-6821-0), but ED certainly came out soon, long before the ASCII bit was officially dropped. Anyway, I don't know whether it supported ASCII mode or not. sas
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
The ASCII feature of S/360 probably wasn't used because it's nearly useless. Turning on ASCII mode caused PACK & CVD to generate ASCII sign codes and UNPK to generate ASCII zone codes. As far as I can tell, that's it. I'd say that the much later PKA & UNPKA instructions make a lot more sense than a system option, so I suppose somebody thinks the function is useful. But you could always convert zoned decimal with NC/OC or, of course TR. ED isn't in my very old S/360 PoOp (A22-6821-0), but ED certainly came out soon, long before the ASCII bit was officially dropped. Anyway, I don't know whether it supported ASCII mode or not. sas
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
Regarding system integrity, I think it will always be totally dependent on system programmers, operators, and maintenance engineers. I remember crashing MVS a few times from the main console trying to release a hung job or transaction. Don Higgins d...@higgins.net www.don-higgins.net -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Saturday, August 8, 2020 5:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) On 2020-08-08, at 15:19:05, Charles Mills wrote: > > Or a dozen or more other non-magic ways of getting into supervisor state. > How does this interact with IBM's Statement of Integrity: https://www.vm.ibm.com/devpages/SPERA/istatmnt.html ... IBM will accept all APARs that describe exposures to the System Integrity of MVS ... System Integrity is defined for MVS as the inability of any program not authorized by a mechanism under the customer's control to: • circumvent or disable store or fetch protection • access an OS password-protected or a RACF-protected resource (RACF is the Resource Access Control Facility), or • obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. Of course, "under the customer's control" is a key phrase. > -Original Message- > From: Robert Netzlof > Sent: Saturday, August 8, 2020 10:20 AM > > But do remember that in Ye Gude Auld Days, there was a widely known > "magic" SVC which granted authorization to the user. -- gil
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
Charles,What do you mean by other non-magic ways? If you mean back-door authorization hacks then I have to wonder about there being a dozen or so methods that rely on coopting a mechanism other than an SVC/PC routine, a TRAPx or MC instruction handler or a Program FLIH front-end that handles magic instructions like 0x00FBAD. Keven On Sat, Aug 8, 2020 at 6:03 PM -0500, "Bernd Oppolzer" wrote: I know of at least one event where a site specific SVC which allowed to store into write protected storage stopped a whole MVS system, involving thousand of users (IMS, TSO, Batch, DB2, during day shift), because the store went into address zero "by mistake". Kind regards Bernd Am 08.08.2020 um 23:53 schrieb Paul Gilmartin: > System Integrity is defined for MVS as the inability of any program > not authorized by a mechanism under the customer's control to: > • circumvent or disable store or fetch protection > • access an OS password-protected or a RACF-protected resource (RACF is > the Resource Access Control Facility), or > • obtain control in an authorized state; that is, in supervisor state, > with a protection key less than eight (8), or Authorized Program Facility > (APF) authorized. > > Of course, "under the customer's control" is a key phrase.
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
I am not suggesting anything nefarious or in violation of the Statement. A program that is linkedited (sorry, I just can't get used to saying "bound") with AC=1 and stored into an APF-authorized library -- all documented and above-board and under the customer's control -- can issue MODESET MODE=SUP and get into supervisor state. In addition, various "user" exits run in supervisor state. As do appendage routines IIRC. Etc. APF-authorized products may have PC routines that run in supervisor state. The point of my post was not "oh, z/OS is full of holes." It's not AFAIK, and I did not mean anything of the sort. My point was that there might have been code somewhere that set the ASCII bit on, even if the IBM OSes did not offer a "MODESET SIGN=ASCII" macro instruction. There are several ways that customer or vendor code may have done so in addition to "magic SVCs." And yes, before someone else points it out, my memory of the history of the platform is not perfect. Exactly which of these methods were available back when the ASCII bit was still around is not something that is at the top of my stack. Certainly magic SVCs were less out of fashion back in those days. I would have to think this through, but right off it would seem to me that a semi-magical SVC that did only one thing -- toggling the ASCII bit for its caller -- would not violate the integrity of the box as a whole. There could be some factor I have not thought of; this is an off-hand speculation of moot significance, not a statement to give to your auditor. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, August 8, 2020 2:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) On 2020-08-08, at 15:19:05, Charles Mills wrote: > > Or a dozen or more other non-magic ways of getting into supervisor state. > How does this interact with IBM's Statement of Integrity: https://www.vm.ibm.com/devpages/SPERA/istatmnt.html ... IBM will accept all APARs that describe exposures to the System Integrity of MVS ... System Integrity is defined for MVS as the inability of any program not authorized by a mechanism under the customer's control to: • circumvent or disable store or fetch protection • access an OS password-protected or a RACF-protected resource (RACF is the Resource Access Control Facility), or • obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. Of course, "under the customer's control" is a key phrase.
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
I know of at least one event where a site specific SVC which allowed to store into write protected storage stopped a whole MVS system, involving thousand of users (IMS, TSO, Batch, DB2, during day shift), because the store went into address zero "by mistake". Kind regards Bernd Am 08.08.2020 um 23:53 schrieb Paul Gilmartin: System Integrity is defined for MVS as the inability of any program not authorized by a mechanism under the customer's control to: • circumvent or disable store or fetch protection • access an OS password-protected or a RACF-protected resource (RACF is the Resource Access Control Facility), or • obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. Of course, "under the customer's control" is a key phrase.
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
On 2020-08-08, at 15:19:05, Charles Mills wrote: > > Or a dozen or more other non-magic ways of getting into supervisor state. > How does this interact with IBM's Statement of Integrity: https://www.vm.ibm.com/devpages/SPERA/istatmnt.html ... IBM will accept all APARs that describe exposures to the System Integrity of MVS ... System Integrity is defined for MVS as the inability of any program not authorized by a mechanism under the customer's control to: • circumvent or disable store or fetch protection • access an OS password-protected or a RACF-protected resource (RACF is the Resource Access Control Facility), or • obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight (8), or Authorized Program Facility (APF) authorized. Of course, "under the customer's control" is a key phrase. > -Original Message- > From: Robert Netzlof > Sent: Saturday, August 8, 2020 10:20 AM > > But do remember that in Ye Gude Auld Days, there was a widely known > "magic" SVC which granted authorization to the user. -- gil
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
Or a dozen or more other non-magic ways of getting into supervisor state. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert Netzlof Sent: Saturday, August 8, 2020 10:20 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987) But do remember that in Ye Gude Auld Days, there was a widely known "magic" SVC which granted authorization to the user. On 8/8/20, Doug Wegscheid wrote: > Site-specific SVC to do so? > > On Saturday, August 8, 2020, 12:11:14 PM EDT, > wrote: > > Interesting are the two paragraphs on page 302, bottom RHS. > > Case says that nobody used the ASCII capability of the S/360. > > Padegs says that "none of our operating systems were [sic] programmed > to turn in the [ASCII] bit". > > So, no-one was able to use the ASCII facility. > > On 2020-08-08 12:19, Jim Mulder wrote: >> https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf >> >> >> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >> Poughkeepsie NY > > -- Bob Netzlof a/k/a Sweet Old Bob
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
The Magic SVC is still at large, along with functionally analogous abominations such as:o The Prodigal PC Routine.o The Munificent MC Function.o The Front-ended (Program) FLIH. These are all harder to discover than a back-door authorization SVC, but all can be found with the right tools and/or an SVC Dump.I guess they’re also listed in order of implementation complexity and overal pervasiveness with regard to the operating system. Finding a hiding place for back door functions is getting harder to the point where some developers are actually considering planning for security before coding begins. Keven On Sat, Aug 8, 2020 at 12:28 PM -0500, "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: On 2020-08-08, at 11:20:25, Robert Netzlof wrote: > > But do remember that in Ye Gude Auld Days, there was a widely known > "magic" SVC which granted authorization to the user. > "Widely known"? But wasn't it always site-specific, never distributed by IBM in a base system? Likewise Installation manuals always urged changing the password for IBMUSER. > On 8/8/20, Doug Wegscheid wrote: >> Site-specific SVC to do so? >> >>On Saturday, August 8, 2020, 12:11:14 PM EDT,robin51 wrote: >> >> Padegs says that "none of our operating systems were [sic] programmed >> to turn in the [ASCII] bit". >> >> So, no-one was able to use the ASCII facility. -- gil
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
On 2020-08-08, at 11:20:25, Robert Netzlof wrote: > > But do remember that in Ye Gude Auld Days, there was a widely known > "magic" SVC which granted authorization to the user. > "Widely known"? But wasn't it always site-specific, never distributed by IBM in a base system? Likewise Installation manuals always urged changing the password for IBMUSER. > On 8/8/20, Doug Wegscheid wrote: >> Site-specific SVC to do so? >> >>On Saturday, August 8, 2020, 12:11:14 PM EDT,robin51 wrote: >> >> Padegs says that "none of our operating systems were [sic] programmed >> to turn in the [ASCII] bit". >> >> So, no-one was able to use the ASCII facility. -- gil
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
But do remember that in Ye Gude Auld Days, there was a widely known "magic" SVC which granted authorization to the user. On 8/8/20, Doug Wegscheid wrote: > Site-specific SVC to do so? > > On Saturday, August 8, 2020, 12:11:14 PM EDT, > wrote: > > Interesting are the two paragraphs on page 302, bottom RHS. > > Case says that nobody used the ASCII capability of the S/360. > > Padegs says that "none of our operating systems were [sic] programmed > to turn in the [ASCII] bit". > > So, no-one was able to use the ASCII facility. > > On 2020-08-08 12:19, Jim Mulder wrote: >> https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf >> >> >> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. >> Poughkeepsie NY > > -- Bob Netzlof a/k/a Sweet Old Bob
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
Site-specific SVC to do so? On Saturday, August 8, 2020, 12:11:14 PM EDT, wrote: Interesting are the two paragraphs on page 302, bottom RHS. Case says that nobody used the ASCII capability of the S/360. Padegs says that "none of our operating systems were [sic] programmed to turn in the [ASCII] bit". So, no-one was able to use the ASCII facility. On 2020-08-08 12:19, Jim Mulder wrote: > https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf > > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
Interesting are the two paragraphs on page 302, bottom RHS. Case says that nobody used the ASCII capability of the S/360. Padegs says that "none of our operating systems were [sic] programmed to turn in the [ASCII] bit". So, no-one was able to use the ASCII facility. On 2020-08-08 12:19, Jim Mulder wrote: https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY
Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
At 8/7/2020 10:19 PM, Jim Mulder wrote: https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY THANKS! Dave Cole :-)
