Hi, I don’t think I can hyperlink so I pasted the whole web page and highlighted where the doc says it pause and relase any task or srb in the system
Choosing a serialization service The serialization service that you choose depends on factors such as the type of processing you need to perform and the scope of your application. For example, your application might require that you serialize resources: •Within a single address space •Across several address spaces within a single MVS™ system •Across multiple MVS systems. Other requirements for your serialization service might include support for SRB mode callers or cross memory capability. Table 1 shows the resource serialization services that are available on MVS, the functions that each service can perform, and where to find more information about each service: Table 1. Summary of Serialization Services Available on MVS Service Function Reference ISGENQ, ENQ/DEQ/RESERVE •ISGENQ: Obtain, change, and release user-defined logical resources (ENQs) and direct access storage device (DASD) Reserves. Serialize resources (such as data sets) within a single MVS address space, single MVS system or across multiple MVS systems. ISGENQ fully supports 64-bit callers. ENQ/DEQ: Obtain, change, and release user-defined logical resources (ENQs). IBM® recommends using the ISGENQ service over ENQ/DEQ/RESERVE. Serialize resources (such as data sets) within a single MVS address space, single MVS system or across multiple MVS systems. Ensure that a routine can complete its use of a resource without interruptions that could cause the routine to end (must-complete function). RESERVE: Allow multiple systems, need not be all MVS, to share direct access storage device (DASD). IBM recommends using the ISGENQ service over ENQ/DEQ/RESERVE. Note: Information regarding requests made to the preceding services can be gathered by ISGQUERY or GQSCAN. Also, ISGADMIN can be used to control certain aspects of the preceding services. See ISGADMIN information in z/OS MVS Programming: Authorized Assembler Services Reference EDT-IXG. •For the ISGENQ macro, see z/OS MVS Programming: Authorized Assembler Services Reference EDT-IXG. For guidance information, see z/OS MVS Programming: Assembler Services Guide and z/OS MVS Planning: Global Resource Serialization. •For the ENQ and DEQ macros, see z/OS MVS Programming: Assembler Services Reference ABE-HSP. For guidance information, see z/OS MVS Programming: Assembler Services Guide. For the must-complete function, see Using the must-complete function (ENQ/DEQ). •Macros used with shared DASD (RESERVE, EXTRACT, GETDSAB) Latch Manager Callable Services: ISGLCRT, ISGLCR64, ISGLOBT, ISGLOB64, ISGLREL, ISGLRE64, ISGLPB64, ISGLPRG, ISGLPR64, ISGLID, ISGLID 64 Serialize resources (such as control blocks or data sets) within a single address space or across several address spaces in a single MVS system with minimal overhead. Authorized programs only. Synchronize the execution of programs. Global resource serialization latch manager Locking (SETLOCK macro) Serialize system resources (such as MVS system queues or control blocks) within a single MVS system or address space. Locking IXLLOCK Enables authorized applications to obtain shared or exclusive serialization on user-defined logical resources. You can also implement your own locking protocols through the inclusion of user data. IXLLOCK is specific to Sysplex environments and provides high speed cross sysplex sharing. The cost is that it is much harder to use then ENQ and provides less external controls For guidance information, see z/OS MVS Programming: Sysplex Services Guide. For the programming environment, see z/OS MVS Programming: Sysplex Services Reference. If you need to synchronize the execution of programs, Table 2 can help you determine which services to choose. The table compares the attributes of the Pause, Transfer, and Release callable services, the WAIT and POST macros, and the SUSPEND and RESUME macros. Table 2. Program Serialization Techniques Description Pause, Release, and Transfer WAIT and POST SUSPEND and RESUME Can change the dispatchability of a task or SRB. Can change the dispatchability of a task but not an SRB. Can change the dispatchability of a task or SRB. Can be called from TCB mode or SRB mode. The interfaces are the same for both modes, and the caller of the services does not need to know whether it is in TCB or SRB mode. WAIT can only be issued in TCB mode. POST can be issued in TCB or SRB mode. The interfaces used in each mode may be different. Can be used in both TCB and SRB mode. The invoking program must know if it is in task or SRB mode. Can release a task or SRB before it is paused Can post a task before it waits. Cannot resume either a task or SRB before it is suspended. An authorized caller can pause and release any task or SRB in the system. Requires the ECB and task being posted to be in the current primary address space for a non-cross memory post. No control element is needed. A task or SRB can only pause on a single Pause Element (PE) at a time. A task may wait on multiple ECBs. If the wait count numbers are posted, the task is made ready. Not applicable. The Transfer service can simultaneously pause one task or SRB and release another. There is no single service with comparable capability for WAIT and POST. There is no single service with comparable capability for SUSPEND and RESUME. The Transfer service can release a task or SRB and immediately pass control to the released task or SRB. There is no single with comparable capability for WAIT and POST. There is not single service with comparable capability for SUSPEND and RESUME. Both authorized and unauthorized callers can use the services. Both authorized and unauthorized callers can use the macros. Only authorized callers can use the macros. The system ensures that pause elements are not reused improperly, thus avoiding improper releases caused by unexpected termination or asynchronous ABENDs. Callers can incorrectly post a task out of the wrong wait due to post, or even the wrong task, if managed improperly, through task termination. Callers can resume the wrong task or resume a task from the wrong suspend. Because no control element serializes SUSPENDs and RESUMEs, neither the system nor the user can easily detect any reuse problems. Local lock is not used by the services; therefore, its usage has no negative effect on local lock contention. Services using local lock can cause additional contention. Services may use local lock, and cause some additional contention. Control the parallel execution of units of work (task or SRB) within the same MVS address space or across MVS address spaces. Allow programs to wait (pause) until one event (RELEASE or TRANSFER) has completed. Control the parallel execution of tasks. Allow programs to wait until one or more events have completed (event completion function). Control the parallel execution of request blocks (RBs) and SRBs within a single MVS system or address space. If you need to serialize resources across multiple MVS systems, you must use the ISGENQ macro or the ENQ/DEQ/RESERVE macro. However, if your application requires resources that reside in a single address space or MVS system, you can choose one of the following services: the CMS lock, ISGENQ, ENQ/DEQ macros, latch manager, the local lock, or IXLLOCK. Table 3 can help you determine which of the serialization services is most appropriate for your application. Table 3. Comparison of CMS Lock, Local Lock, Latch Manager, and ISGENQ and ENQ/DEQ Serialization Services Feature CMS Lock Local Lock Latch Manager ENQ/DEQ Macros ISGENQ Macro Number of items you can serialize individually One One Many Many Many Access allowed Exclusive Exclusive Exclusive and shared Exclusive and shared Exclusive and shared Scope Single system Address space Single system or address space Address space, single system, or multiple systems Address space, single system, or multiple systems Cross memory environment Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN. Unit of work Task or SRB routine Task or SRB routine Task or SRB routine Task Task Minimum authorization Supervisor state and PSW key 0 Supervisor state and PSW key 0 Supervisor state or PSW key 0-7 Problem state with any PSW key, supervisor state or PSW key 0-7 or APF-authorized for certain types of requests Problem state with any PSW key, supervisor state or PSW key 0-7 or APF-authorized for certain types of requests Set-up required None None Application must create one or more latch sets None None Default recovery action Release owned and pending requests Release owned and pending requests Release pending requests, but not owned requests Release owned and pending requests Release owned and pending requests Other techniques, such as those that make use of the compare and swap (CS), compare double and swap (CDS), and test and set (TS) instructions, are provided to perform specialized serialization. For information about those instructions, see Principles of Operation. The capabilities listed in Table 3 are explained below: Number of items you can serialize individuallyThe latch manager and ISGENQ allow your application more control over the way it divides resources into individual units and assigns serialization to those resources. This increased control allows you to reduce contention for resources and improve the overall performance of the application. For example, an application can use several latches to serialize resources within an address space, instead of using the address space local lock (of which there is only one) to serialize those resources.Access allowedGranting shared access minimizes resource contention because several requestors can read a resource at the same time. The CMS and local locks do not provide shared access to resources. Each unit of work that requests the CMS or the local lock must obtain exclusive access, even though shared access might be enough. The latch manager and the ISGENQ macro allow programs to request shared or exclusive access to resources.ScopeThe CMS lock and the latch manager can be used to serialize resources only within a single MVS system. The local lock is restricted to a single address space. The ISGENQ macro can be used to serialize resources across multiple MVS systems (as well as a single MVS system).Cross memory environmentWith a cross memory environment established, your application can use the CMS lock, latch manager, or local lock to serialize resources across address spaces within a single MVS system. When the latch manager is being used in a cross memory environment, the current latch set must reside in the primary address space.Unit of workThe CMS lock, local lock, and latch manager are available to programs that run in task or SRB mode. The ISGENQ macro is available only to programs that run in task mode (SRB routines cannot issue ENQ/DEQ).Minimum authorizationPrograms must run in supervisor state and PSW key 0 to obtain the CMS or local lock, and supervisor state or PKM 0-7 to obtain a latch. The ISGENQ macro is available to programs running in problem state with any PSW key. Supervisor state, PSW key 0-7, or APF authorization is required for certain types of ISGENQ requests.Set-up requiredThe CMS lock, local lock, and the ISGENQ macro do not require applications to perform any set-up; the system creates the required structures. Before your application can use the latch manager to serialize resources, the application must create one or more latch sets.Default recovery actionFor the local and CMS locks, the system releases owned and pending serialization requests when the last functional recovery routine (FRR) percolates. For the ISGENQ macro the system releases owned or pending serialization requests during task or address space termination. (See "Releasing the Resource" in z/OS MVS Programming: Assembler Services Guide for more discussion about what happens when a task associated with an ENQ terminates before the ENQ is released.) For performance reasons, and because SRBs might not want to release owned latches when errors occur, the system does not release owned latch requests during task or address space termination. The system does, however, release pending latch requests when the requestor's home address space terminates. In all cases, the application programmer needs to understand the default recovery action for the service that is used. For more information on how to create a recovery environment, see the information that discusses recovery and termination. Parent topic: Serialization -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, October 16, 2015 8:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEAVAPE2/IEAVPSE2 another address space On Fri, Oct 16, 2015 at 6:27 AM, michealbutz <michealb...@comcast.net> wrote: > Hi > > The documentation says that IEAVAPE2/IEAVPSE2 Can pause any Task or > Srb in the system > > I got/allocated stoken or ASSBSTKN of the target address space I > wanted to pause via IEAVAPE2 successful return code > > When I tried to run IEAVPSE2 the service never returned fronm the BALR > it just hung (this was with the linakge branch parm) > > I ran this under TESTAUTH (to ensure everything was correct) > > When I cancelled the target address space IEAVPSE2 returned from the > balr with a zero return code > > The documentation seemed to indcate I could this pause another address > space > Can you give a reference? I ask because I read here: https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa200/ieavpse.htm <quote> IEAVPSE2 — Pause service Description Call Pause to make the current task or SRB nondispatchable. When you pause a task or SRB, it remains nondispatchable until a Release or Transfer specifying the same PET is called. That is, the program issuing the Pause does not receive control back until after the Release or Transfer occurs. At that time, the returned release_code will contain a value supplied by the associated Release or Transfer request. If a Release service specifying the same PET is called before Pause, the system returns control immediately to the calling program, and the task or SRB is not paused. When you use Pause, it returns an updated PET; you use this updated PET to either deallocate or reuse the PE. </quote> Reading this, I take it to mean that the "dispatchable unit" which issues the IEAVPSE2 call is the one which is paused. I gather what you want is a way for a program ("A") in one address space (ASID1) to pause a different program ("B") in a different address space. If I may, a kind of remote control ON/OFF switch. Again, just from reading & not experience, a normal PE (IEA_PET_UNAUTHORIZED) is created by and can be used in only a single address space. But an APF program can create an "any address space" PE (IEA_PET_AUTHORIZED) which can be used by an APF program in _any_ address space to pause _itself_ (not another). This latter allows APF program "A" in ASID1 to do the IEAVPSE2 to pause itself. And then APF program "B" in ASID2 can do an IEAVRLS2 to allow program "A" to start running again. I guess this is the equivalent of a cross memory POST. It also allows that PET to be used by any address space (serially) in the system, rather that just a program running in the address space which allocated the PE. Am I reading you correctly? You want some way for program "A" (ASID 1) to just cause program "B" (ASID 2) to stop immediately, where ever it is, without program "B" doing anything to allow/disallow it. This reminds me, vaguely, of doing a STATUS STOP on a child TCB to "put the brakes on" for that child TCB, without the program in the child doing anything. I don't think that pause / release / transfer is the function you want. And, before you ask, I don't know of a way to do this. Well, not a nice GUPI way. Especially if you want to stop an SRB's execution. Of course, you could schedule an SRB into the proper address space, have it schedule a CIRB to run on a given TCB which would then issue the IEAVPSE2. Or just cheat by going key 0 and setting the target address space non-dispatchable by messing with it's ASCB. I now expect a nasty note from Mr. Relson about the undesirability of doing this. Please don't try this with *MASTER* or CONSOLE or ???? > Thanks > > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
