It would be very surprising if there were any limitation on the scope of a data space other than what the ALET itself represents.
Limitations are typically with respect to the ALET itself -- DU-AL (Dispatchable Unit Access List) ALET vs PASN-AL (PASN Access List) ALET vs a common area data space (DSPSERV with SCOPE=COMMON) ALET (which is on the PASN-AL), and public entry vs private entry. -- All services that I can think of that accept ALET-qualified data accept an ALET for a public entry on the DU-AL. Most do not accept an ALET for a private entry. -- Many services also accept a CADS on the PASN-AL. -- Most services do not accept an ALET that is on the PASN-AL but does not represent a CADS. -- Many services do not accept a CADS ALET either. If you had a real case for requiring that, I'd imagine that an RFE would be accepted to enhance to accept a CADS ALET. I have not seen any service differentiate between the ALET for a SCOPE=ALL and a SCOPE=SINGLE data space. But I suggest that you not assume that a CADS ALET is OK. You might see documentation such as this: Control parameters must be in the primary address space or, for AR-mode callers, must be in an address/data space that is addressable through a public entry on the caller's dispatchable unit access list (DU-AL). Note that that wording does not say that a CADS is OK. If it is OK, and if we want use of a CADS to be part of the programming interface, we ought to clarify the doc to say so. But please do not assume. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
