Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] # z/OS V1.13 is planned to be the last release to support BPX.DEFAULT.USER. IBM recommends that you either use the BPX.UNIQUE.USER support that was introduced in z/OS V1.11, or assign unique UIDs to users who need them and assign GIDs for their groups. Good riddance? But will some admins complain? Some already have, on RACF-L. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
On Tue, 5 Jul 2011 19:15:45 -0500, Paul Gilmartin wrote: What's the rationale for bit 12? It must be 0 for LPSWE and 1 for LPSW, but in either case a 0 is loaded into the PSW. In the System/360, bit 12 was the USASCII bit. It controlled the operation of only a few instructions. UNPK was one. System/370 removed the USASCII support and bit 12 was required to be 0. Later, when virtual addressing was added, a 1 in bit 12 signified Extended-Control mode. This enabled Dynamic Address Translation and changed the format of the PSW. Some time later, Basic-Control mode was removed and bit 12 was required to be set to 1. z/Architecture introduced a 128-bit PSW and in z/Architecture mode, bit 12 in the PSW must be 0. LPSW inverts the value in bit 12 and LPSWE leaves it alone. Perhaps st some time in the future, IBM will define something new in the architecture that requires another change in the PSW and bit 12 will be used to signify the change. Then again, maybe not. In any case, when looking at a dump in storage, bit 12 tells whether it is a 64-bit or a 128-bit PSW. But none of this would seem to support forming a 64-bit PSW when an interrupt [occurs] while executing above the bar. When an interrupt occurs, the 128-bit PSW is stored. In order to be able to run interruptable work above the bar, the 128-bit PSW must be preserved and used to dispatch the program again. AFAIK, IBM has not said how they will do that. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEBCOPY in z/OS R13 (was (re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???))
On Tue, 5 Jul 2011 19:15:45 -0500, Paul Gilmartin paulgboul...@aim.com wrote: # Enhancements are planned for the IEBCOPY utility that are intended to improve performance when copying a partitioned data set (PDS) to another PDS. In addition, IEBCOPY is planned to exploit 31-bit storage for track buffers, and the current requirement for APF authorization is planned to be removed in z/OS V1.13. Wow! Then I could run SMP/E also without APF authorization, provided I avoid using the WAIT option on DDDEFS. Could this result in a relaxation of the constraints introduced by the notorious APAR IO11698? I insist on my view that if a program operating without APF authorization can leverage an integrity exposure, the OS itself needs repair; it is insufficient to repair that program or restrict access to it. You don't need to insist on (your) view, gil. That's the basic idea of our z/OS Integrity Statement. Unauthorized programs must not be able to compromise the system in contravention of the security and integrity controls the system implements. (That's just my unofficial rephrasing, for the purpose of this discussion, by the way, and not an official IBM statement of our policy.) The issue with SMP/E that resulted in that APAR is different, though, as SMP/E -does- operate with APF authorization, and therefore applying some restrictions (such as over who can run it) is an appropriate control mechanism, but it's not the situation you mention above (restricting who can run an unauthorized program). Additionally I'll note that we do allow unauthorized programs to perform sensitive operations under the control of a RACF authorization check. While one might view that as a form of restricting access to the program, it's really a control implemented at a lower level, within the system itself. And so we view that as an appropriate control mechanism. One example (among many) is that an unauthorized programs with authority to an appropriate CSVAPF-prefixed resource in the FACILITY class can make changes to the system APF configuration. But if you don't allow it via that FACILITY check, the action is not allowed unless the program runs authorized. If an unauthorized program were able to take that action, without having the appropriate RACF authority, then yes, I would agree that the OS is broken and needs a fix, and that asking you to restrict access to the program itself (e.g., via RACF PROGRAM control, or restricting access to the load library) would not be appropriate. By the way, I have no idea if or when we might plan to change SMP/E so it runs unauthorized, but I consider the change to IEBCOPY to be one step in the right direction that might help allow that change one day. I also have no idea what it would mean for the authorization checks that SMP/E APAR introduced, but that's clearly something for us to consider someday, too. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
On Tue, 5 Jul 2011 12:38:25 -0400, Jim Mulder wrote: The z/OS 1.13 preview (Feb 15, 2011) says: I must have been napping about then. But I checked the IBM-MAIN archives around mid-February, and I can't readily find a URL for this. Help! z/OS will be designed to support some programs running in 64-bit storage, provided that they meet certain restrictions. This is intended to provide virtual certain restrictions. Does this restrict ATB execution to contexts such that the PSW needn't appear in a TCB or an RB, or will there be support for unscrunched PSWs in those control blocks? (Or must I wait for the full announcement?) storage constraint relief to applications, particularly those that imbed code in data areas for performance reasons. Why would there be an advantage to imbedding code in data areas? Sometimes this disrupts pipelining; the conventional wisdom is to keep code and data in separate pages, isn't it? Does it facilitate baseless coding? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
Try here: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=an supplier=897letternum=ENUS211-007 or search ibm.com for 211-007 HTH, snip The z/OS 1.13 preview (Feb 15, 2011) says: I must have been napping about then. But I checked the IBM-MAIN archives around mid-February, and I can't readily find a URL for this. Help! z/OS will be designed to support some programs running in 64-bit storage, provided that they meet certain restrictions. This is intended to provide virtual /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
On 5 July 2011 13:28, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 5 Jul 2011 12:38:25 -0400, Jim Mulder wrote: storage constraint relief to applications, particularly those that imbed code in data areas for performance reasons. Why would there be an advantage to imbedding code in data areas? Sometimes this disrupts pipelining; the conventional wisdom is to keep code and data in separate pages, isn't it? Does it facilitate baseless coding? I suspect it's a larger scale than that. The OO paradigm has objects, with both code and data (uh, methods and fields) in one logical place, but not necessarily so close together as to cause cache line discards. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
On 7/5/2011 10:28 AM, Paul Gilmartin wrote: z/OS will be designed to support some programs running in 64-bit storage, provided that they meet certain restrictions. This is intended to provide virtual certain restrictions. Does this restrict ATB execution to contexts such that the PSW needn't appear in a TCB or an RB, or will there be support for unscrunched PSWs in those control blocks? (Or must I wait for the full announcement?) The operating system control blocks now handle 64-bit PSWs such that an interrupt while executing above the bar is supported. No abend occurs. storage constraint relief to applications, particularly those that imbed code in data areas for performance reasons. Why would there be an advantage to imbedding code in data areas? Sometimes this disrupts pipelining; the conventional wisdom is to keep code and data in separate pages, isn't it? Does it facilitate baseless coding? It is often convenient to embed custom-generated code to handle custom-generated data within the data itself. Without support for above-the-bar execution, such programs would need to manage two areas for each data structure: one above the bar and one below the bar. Of course, code and data must be in separate cache lines. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
On Tue, 5 Jul 2011 13:17:26 -0700, Edward Jaffe wrote: The operating system control blocks now handle 64-bit PSWs such that an interrupt while executing above the bar is supported. No abend occurs. They put a 64-bit address in a 64-bit PSW? This leaves precious little room for flags. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
PSW on a z machine is 128 bits or 16 bytes or 4 fullwords aka a quadword. z/OS compresses this to a doubleword by assuming that the instruction address is below 2 GiB and eliminates a lot of the bits which are always set to 0 because they are currently unused by the hardware (must be zero?). See page 4-5 of the current POPS. On Tue, 2011-07-05 at 16:53 -0500, Paul Gilmartin wrote: On Tue, 5 Jul 2011 13:17:26 -0700, Edward Jaffe wrote: The operating system control blocks now handle 64-bit PSWs such that an interrupt while executing above the bar is supported. No abend occurs. They put a 64-bit address in a 64-bit PSW? This leaves precious little room for flags. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
On 7/5/2011 2:53 PM, Paul Gilmartin wrote: On Tue, 5 Jul 2011 13:17:26 -0700, Edward Jaffe wrote: The operating system control blocks now handle 64-bit PSWs such that an interrupt while executing above the bar is supported. No abend occurs. They put a 64-bit address in a 64-bit PSW? This leaves precious little room for flags. LOL! Sorry, I often loosely use the adjective '64-bit' to describe any structure that supports AMODE(64) programs. I should have said the 128-bit or z/Architecture PSW. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)
On Tue, 5 Jul 2011 17:52:39 -0500, John McKown wrote: PSW on a z machine is 128 bits or 16 bytes or 4 fullwords aka a quadword. z/OS compresses this to a doubleword by assuming that the instruction address is below 2 GiB and eliminates a lot of the bits which are always set to 0 because they are currently unused by the hardware (must be zero?). See page 4-5 of the current POPS. OK. (I now must log in to get the PoOps!?) I looked at that, and p. 4-6, and Chapter 6 (briefly) and LPSW and LPSWE. Is scrunch official terminology or something an IBM employee used casually in these pages? I'm delighted that unassigned bits are required to be zero, else a specification exception is recognized, and it won't dispatch to an instruction address inconsistent with the AMODE. Apparently an interruption always saves a 16-byte PSW. It must be a responsibility of software in the FLIH to form an 8-byte PSW if needed for LPSW. What's the rationale for bit 12? It must be 0 for LPSWE and 1 for LPSW, but in either case a 0 is loaded into the PSW. But none of this would seem to support forming a 64-bit PSW when an interrupt [occurs] while executing above the bar. On Tue, 2011-07-05 at 16:53 -0500, Paul Gilmartin wrote: On Tue, 5 Jul 2011 13:17:26 -0700, Edward Jaffe wrote: The operating system control blocks now handle 64-bit PSWs such that an interrupt while executing above the bar is supported. No abend occurs. They put a 64-bit address in a 64-bit PSW? This leaves precious little room for flags. Other comments on the Preview wherein I also read: # Enhancements are planned for the IEBCOPY utility that are intended to improve performance when copying a partitioned data set (PDS) to another PDS. In addition, IEBCOPY is planned to exploit 31-bit storage for track buffers, and the current requirement for APF authorization is planned to be removed in z/OS V1.13. Wow! Then I could run SMP/E also without APF authorization, provided I avoid using the WAIT option on DDDEFS. Could this result in a relaxation of the constraints introduced by the notorious APAR IO11698? I insist on my view that if a program operating without APF authorization can leverage an integrity exposure, the OS itself needs repair; it is insufficient to repair that program or restrict access to it. And: (Steve C. mentioned this in February): # Support is planned for in-stream data sets to be used within JCL procedures and for include statements. ... and: # JCL enhancements are designed to make programming JCL easier, and give you more control of your batch applications. Functions such as in-stream data in catalogue procedures, ... Is catalogue[d] a requirement, or does the enhancement also pertain to in-stream procedures? The adjective is present in the later paragraph; absent from the earlier. (Yah, I know, it's only a preview.) What is it trying to say about include statements? Now we need symbol substitution in in-stream data sets. # Access Method Services (IDCAMS) is planned to support a new option for the LISTCAT LEVEL command. This new option is designed to allow you to specify whether related component names be listed when a data set entry is listed based on the pattern specified by LEVEL. For example, if a cluster name is listed, the new option is designed to allow you to specify whether the DATA and INDEX entries are also listed. This is intended to make it easier to customize LISTCAT output and reduce unwanted or unneeded LISTCAT data. Will this facility be extended to ISPF DSLIST? The clutter has long been a (minor) annoyance. # A new utility, IEBPDSE, will be designed to verify that the structure of a PDSE is valid, ... fsck for PDSE!? # z/OS V1.13 is planned to be the last release to support BPX.DEFAULT.USER. IBM recommends that you either use the BPX.UNIQUE.USER support that was introduced in z/OS V1.11, or assign unique UIDs to users who need them and assign GIDs for their groups. Good riddance? But will some admins complain? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
