Hi, You don't have to define anything to RACF to use IPCS but you can do some really useful analysis of a live system if you do.
If you define BLSACTV.ADDRSPAC and BLSACTV.SYSTEM to the FACILITY class you can use IPCS as a fairly powerful storage browser. In anything but an ISV sandbox you would want to define these with UACC(NONE) and permit use on limited basis. Bob Rogers talked about the new capability briefly during his session 2878 - z/OS 1.9: Sysprog Goody Bag at SHARE in Orlando. SYSTEM is new ADDRSPAC previously existed and functionality has been enhanced. http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_ Orlando/S2878RR181322.pdf Live system analysis with IPCS IPCS ACTIVE Users with no special authorization now can ask IPCS ACTIVE to access data spaces that unauthorized code can see that are owned by the ASID. Facility class BLSACTIVE ADDRSPAC read access now permits all data spaces owned by the ASID to be viewed. Facility class BLSACTV SYSTEM read access now permits access to the following: ABSOLUTE storage, All ASIDs, All data spaces IPCS does not serialize (Caveat emptor) Static areas of the system can yield good analysis Areas of the system that are altered frequently cannot | Storage is accessed incrementally on demand, and IPCS generally | remains enabled. As a result, ACTIVE storage might be subject to | frequent changes, which can prevent the analysis programs from | producing useful results. | ABSOLUTE, ASID, DSPNAME, and HEADER keywords are supported. Access to | sensitive storage areas, such as ABSOLUTE, is limited using facility | classes. When the user does not have the authority, the access | attempts are handled as though the storage in question was not | included in a dump. | With no special authority, IPCS can access the following storage: | The common and private storage in its own ASID visible to a key 8 | application | The data spaces owned by its own ASID and visible to a key 8 | application | Before z/OS V1R9 no data space access was supported. | With read authority to facility class BLSACTV.ADDRSPAC, IPCS can look | at the following storage (in addition to those storage areas it can | access with no special authority) : | The common and private storage visible to a key 0 application | All data spaces owned by its own ASID | Before z/OS V1R9 no data space access was supported. | With read authority to facility class BLSACTV.SYSTEM, IPCS can look at | the following storage (in addition to those storage areas it can | access with no special authority) : | The ABSOLUTE storage | Other ASIDs | The data spaces owned by other ASIDs | BLSACTV.SYSTEM support was added in z/OS V1R9. | Note: IPCS artificially attributes CADS ownerships to ASID(1) as it | also does for the page frame table space, ASID(1) | DSPNAME(IARPFT). Consistent with this perspective | BLSACTV.SYSTEM authority is required to access these data | spaces. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Friday, April 11, 2008 4:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Workable Mainframe Debuggers Farley, Peter x23353 wrote: > I've rarely been in a shop that had IPCS That *had* IPCS?? It comes with the system! > and also permitted application > programmers to use it. I'm not aware of any SAF call or other method to prevent application programmers or anyone else from issuing the IPCS command under TSO/E. Is there?? Perhaps some popular, home-grown way of preventing IPCS access for all but sysprogs?? If so, why? Is there also some sort of popular exit to prevent them from placing SYSMDUMP DD statements into their jobs? > I started in MVT and then early VM/VSE/SP > environments with some VS1 on the side. By the time I moved to MVS > shops, they were so large that they followed the rule: "Everything > permitted is mandatory; everything else is forbidden." > -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
