ASID (Address Space Identifier) and ADABAS

, , ,
1

My questions:

  1. Does ADABAS render an address space (ASID) non-reusable when it terminates?

If yes to question 1 above,

2.why does it do so? any reason …
3. Is it possible to control it? and how? (other than IPL to reset)

Context: Recently on the question of running out of non-reusable ASID’s (RSVNONR) it may have been attributed to ADABAS. I want to know if it is true / possible etc. and if so … can we do anything to prevent it.

Regards Feroz

2

I think that z/OS marks the ASID as non-reusable, not Adabas. The explanation that I was given (correct or incorrect) is z/OS does this for a cross-memory target ASID.

In newer versions of z/OS there is a reuse ASID parameter. Adabas supports the parameter.

3

That is correct. When we went to monthly IPLs instead of weekly ones, this became apparent to our mainframe platform folks.

You can do any of the following corrective actions to avoid exhaustion of your address space pool:

  1. Size the pool of address spaces to not exhaust them between planned IPLs.

  2. Don’t bring down ADABAS except for planned IPLs.

  3. Have ADABAS always started with REUSASID=YES (e.g., /S adampm,REUSASID=YES).

We have gone with the third option.

4

That is correct. When we went to monthly IPLs instead of weekly ones, this became apparent to our mainframe platform folks.

You can do any of the following corrective actions to avoid exhaustion of your address space pool:

  1. Size the pool of address spaces to not exhaust them between planned IPLs.

  2. Don’t bring down ADABAS except for planned IPLs.

  3. Have ADABAS always started with REUSASID=YES (e.g., /S adampm,REUSASID=YES).

We have gone with the third option, though they have increased the ASID pool and we are working towards #2 as well.

5

you can as well read more details in the documentation here: http://techcommunity.softwareag.com/ecosystem/documentation/adabas/ada833mfr/adamf/install_os3/install-zos.htm#cross-memory

You need access to Empower 8)

6

Thanks for all the valuable input Brian / Ursula.