Scott I assume you want to use the dataspace as some sort of common buffer for copying away data discovered by the system exit. I will also assume that the exit can execute in a variety of home address spaces in the system.
If so, then an accepted way of achieving this with dataspaces is to use a SCOPE=COMMON dataspace (aka CADS). Once created, the ALET for the dataspace is automatically included on the PASN of all address spaces in the system (it occupies one of the reserved slots that are established using the MAXCADS system parameter). Your system exit does NOT need to ALESERV before it uses the CADS - it just has to know where the CADS owner (your long-running STC) has stored the ALET for the CADS (typically in some sort of common storage anchor - maybe off the SSCT chain or a system name/token). Once it has the ALET for the CADS, it can prime an AR and access the data in the dataspace. Note that a CADS is a limited resource and careless (or over-enthusiastic) use can exhaust them and prevent other software from initializing correctly and could require an IPL to fix. It is also worth pointing out that your long-running STC needs to protect its client users (ie anyone writing to or reading from) the CADS from any expected or unexpected withdrawal from the system. Recovery routines, resource managers and careful design is required to protect the integrity of your application and the system. In today's 64-bit enabled environments, there are alternatives to using CADS, for example : 64-bit common storage and shared 64-bit memory objects. You could also consider a PC-ss routine (system-LX) to transfer the data directly to the private storage of your STC. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com
