Adabas has supported a reliable backup while active for several decades (1980s)
> -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of John Blythe Reid > Sent: Monday, January 10, 2022 7:22 AM > To: [email protected] > Subject: Re: Available ASIDs low and dropping > > Rob, > > ADABAS does support REUSASID=YES: > > The address space ID (ASID) representing this address space is not > reassigned until the next IPL. Therefore, you should choose a sufficiently > high value for the MAXUSERS parameter in the active IEASYSxx member of > SYS1.PARMLIB or—if your system supports it—the RSVNONR parameter in > the same member can be adjusted accordingly. Also, the Adabas nucleus > should not be stopped and started without good reason. This is described in > the manuals referred to in the topics Recovery Considerations and Resource > Management. Additional information can be found in IBM APARs OZ61154, > OZ61741, and OZ67637. > > To reduce the possibility that the system will run out of ASIDs for assignment > to new address spaces, start ADABAS with REUSASID=YES: > > /S ADAxxxx,REUSASID=YES > > This is described in the IBM z/OS manual MVS Programming Extended > Addressability Guide. > ---------------------------------------------------------------------------------------------- > ------------------------------------------------------------- > To make its services available to all address spaces in the system, the Adabas > nucleus must obtain a system linkage index (LX) from z/OS. The LX is a > reserved slot in the linkage space of all address spaces, and permits system- > wide linkage to all address spaces. > > If your hardware supports the Address Space and LX Reuse Facility (ALRF), > the version 8 ADASVC will make use of reusable systems LXs. Otherwise, a > non-reusable system LX will be used as in previous releases. Reusable > system LXs resolve the constraints imposed by non-reusable LXs. The > remainder of this section discusses these constraints. > > The number of non-reusable LXs set aside by z/OS for system use is rather > small (usually 165 out of a possible 2048). > > Because of the way z/OS use cross-memory services, non-reusable system > LXs obtained by Adabas cannot be returned to z/OS until the next IPL. > However, the system that owns the LXs can reuse them, even for a different > address space. Adabas makes use of this feature by identifying used LXs in a > table in CSA, where they are available to future nuclei. > > The number of non-reusable system LXs can be specified in the member > IEASYSxx contained in SYS1.PARMLIB, using the NSYSLX parameter. If you > change this value, you must perform an IPL to make the change effective. > ---------------------------------------------------------------------------------------------- > ------------------------------------------------------------- > > As it says here the Adabas nucleus regions should only be stopped for a good > reason. I think the only reason the client recycles them every week is to do > an offline backup which is what they've always done. > > Because the currently active Adabas nucleus regions were started without > REUSASID=YES when they terminate on Monday that'll trigger this error as > there will only be 20 available ASIDs with MAXUSER at 500: > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------- > IEA059E ASID SHORTAGE HAS BEEN DETECTED > Explanation > The number of ASIDs available for allocation to new address spaces has > dropped below 5% of the value specified in IEASYSxx with the MAXUSER > specification. > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------- > Putting REUSASID=YES in the Adabas nucleus start-up procs will hold the > available ASIDs at 20 but that's too low and too late. It's a pity the alert > didn't > trigger sooner. > > It looks like there'll have to be an IPL. The first in two years for this > LPAR. > > Thanks you all for your help. > > Regards, > John. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
