Perhaps old stuff, but we're at z/OS 1.13 for production and our systems programmer announced a SMP/E upgrade, so I searched and found: http://www-03.ibm.com/systems/z/os/zos/features/smpe/whats-new/ SMP/E for z/OS V3R6 new function
Multitasking using GMDDALC SYSPRINT allocation Previously, SMP/E required the use of a DDDEF for SYSPRINT dynamic allocation in order to permit multi-tasking during Binder link-edit activities. In V1R13, SMP/E processing was modified to support multi-tasking using a SYSPRINT definition in the GIMDDALC data. When change was introduced: z/OS V1R13. There was a recent thread here discussing capturing SMP/E SYSPRINT. Might this be relevant, either resolving or introducing the difficulty mentioned? I gotta research GMDDALC (or perhaps GIMDDALC). New SAF checks for SMP/E processing As an authorized program, SMP/E must ensure that any programs it calls that reside in an authorized library are called only in expected environments with expected parameters. In V1R13, SAF checks were added to ensure that only users with sufficient access authority are allowed to invoke certain SMP/E functions. When change was introduced: z/OS V1R13. Does this relax the 4-year old general requirement for SAF authorization for almost any use of SMP/E (and GIMZIP, etc.)? "... called only in expected environments with expected parameters." That's a massive amount of utility-specific syntax and semantic checking. Does it validate SYSIN for IEBUPDTE and AMASPZAP, etc.? Does it prohibit specification of arbitrarily named utilities residing in authorized libraries, or merely verify that the supplied parameters are suitable for the standard utilities, whatever replaces them? I'm dumbfounded. Or does "SMP/E must ensure" mean that the responsibility for such assurance is passed to the SAF-authorized programmer? In any case, there's now sufficient characterization of the exposure (but still with no identification of the specific utility at risk) that prolonged security by obscurity is hardly mandated. And the SAF-authorized programmer now (belatedly) knows what hazards to avoid. Perhaps the Info APAR and Reference Manuals should be updated accordingly. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
