IBM Support

II05264: ASVT SLOT USAGE, POSSIBLE ABORTED LOGON COMMANDS.

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as user error.

Error description

  • The customer receives error message(s) when an address space
    is being created. The message(s) may include:
       msgIKT00203I ADDRESS SPACE CREATION FAILED
       msgIEE328I "LOGON COMMAND ABORTED"
       msgIEA061E REPLACEMENT ASID SHORTAGE HAS BEEN DETECTED
       msgIEA602I ADDRESS SPACE CREATE FAILED.
                    MAXUSERS WOULD HAVE BEEN EXCEEDED.
     The message IEA602I, IEE328I or IKT00203I symptoms usually
    indicate that the system has run out of slots in the ASVT
    (Address Space Vector Table), the supervisor table which maps
    ASID's to ASCB's.  The Size of this table, and thus the
    total number of ASIDs that can initialized until the system
    is re-ipl'd is determined during IPL by the values specified
    in the MAXUSER, RSVNONR, and RSVSTRT options of the IEASYSxx
    parmlib member.
     The total number of address spaces that can be initialized at
    one time, during the life of an IPL is controlled by the total
    of IEASYSxx parameters MAXUSER and RSVSTRT. When any new ASID
    is to be started, Supervisor first determines if there are any
    slots available for the ASID on the ASVT MAXUSER queue. If the
    MAXUSER queue is filled, and if then the address space to be
    started is a started task, the ASVT slot may be satisfied from
    an unused slot on the RSVSTRT queue. If there are no slots
    available on either MAXUSER or RSVSTRT queues the address space
    will not be initialized.
     If the ASVT MAXUSER queue is filled and the ASID being
    initialized is a TSO user, msgIEE328I and msgIEA602I will be
    seen. Normally, when an address space ends, if no cross memory
    binds exist, the ASVT slot is returned to the MAXUSER queue.
    Thus, for each logoff that occurs, one logon should be allowed.
    However, if the total MAXUSER has been reached, subsequent
    logon attempts will again result in the IEE328I and IEA602I
    messages being issued. An IPL is usually the only way to
    alleviate the problem.  Additionally, IKT00203I may be seen.
     The RSVNONR specification reserves a number of ASVT slots to
    replenish ASVT slots in the MAXUSER or RSVSTRT 'pools' which
    are marked non-reusable at address space termination. There
    are times in the life of an ipl when an address space will
    go away and its corresponding slot in the ASVT will be
    marked non-reusable. When this occurs, the non-reusable slot
    is replaced by a slot from the RSVNONR pool.  However, once
    the RSVNONR pool is exhausted, the slots in the MAXUSER or
    RSVSTRT pool cannot be replaced and are often lost for the
    remainder of the IPL.
     When the number of RSVNONR slots falls below 5% of that
    specified in IEASYSxx, the system produces:
       msgIEA061E REPLACEMENT ASID SHORTAGE HAS BEEN DETECTED
    IEA061E is an indication that address space termination may
    soon result in a decrease in the number of active ASIDs that
    may be running (IE:  the MAXUSER or RSVSTRT pools will not be
    replenished). Again, it may require an IPL to alleviate the
    non-reusable address spaces, but the urgency of the IPL will
    depend on two factors;
     -MAXUSER slots available (indicated by ASVT +x'1E0' field
      ASVTAAV).
     -The depletion rate due to ASID termination with cross
      memory binds. RSVNONR availability can be determined via
      the ASVTANR field as shown below.
    For example, if at peak processing, 20 MAXUSER slots are
     still available (unused), and the slot depletion rate is
     5 a day, you may still have up to 4 days before an IPL will
     be necessary.
     If cross memory binds are freed, and the RSVNONR pool is
    replenished such that it is at least 10% of its original
    specification, IEA062I will be issued:
     msgIEA062I REPLACEMENT ASID SHORTAGE HAS BEEN RELIEVED
    *
       The most common reason for a slot in the ASVT to be marked
    non-reusable is that the corresponding address space has gone
    down with cross-memory connections or binds.  Due to system
    integrity concerns, the ASID cannot be reused until these binds
    are broken.  Please see APAR OY26621 for additional information
    about this problem of cross memory binds and what operational
    procedures may be performed to minimize the number of address
    spaces that terminate with unbreakable cross-memory connections.
       Note that the termination of DB2 regions is a major cause
    of slots being marked non-reusable. APAR OY26621 discusses
    non-reusability with particular emphasis on DB2 address
    spaces. For information on  non-reusability associated with
    PSF address spaces, please see JES2 apar OY22901.
    Also, see OY55392 for additional documentation on
    non-reusable slots.
       To determine if a system is, in fact, out of usable slots in
    the ASVT, the customer can look at the ASVT in an SVC dump, a
    standalone dump, or by browsing the active system if it is still
    in this problem state. The ASVT is pointed to by the
    CVT + x'22C'. The ASVT eyecatcher is located at ASVT + x'200'.
    The following data from the ASVT will confirm that the system is
    out of slots:
    
      1) ASVTANR  (+x'1E8') = 0.
        Indicating the number of free RSVNONR slots is zero.
      2) If pre HBB7709, if ASVTDSHD (+x'1FC') = x'80000000'.
        It indicates the first free RSVNONR slot is assigned.
      3) ASVTAAV  (+x'1E0') = a very low number (<=5).
        Indicating very few slots on the available queue.
      4) ASVTFRST (+x'20C') may be x'80000000'.
        Indicating the first free available queue slot is assigned.
    
    
    Again, if ASVTAAV is not low, the IPL urgency is dependant on
     the ASVT slot depletion rate.
    The slots in the ASVT begin at ASVT + x'210'. A slot has been
    marked non-reusable if its high order bit is on, and the
    address in the slot points to ASVT + x'210'. On a system
    which is experiencing a problem due to ASVT slots being
    marked non-reusable, all or nearly all slots which have
    the high order bit on will point to ASVT + x'210'.
      At OS/390 r1.2 and earlier, the system provides no way of
    identifying the job last associated with an address space
    that has been marked non-reusable. Please contact Supervisor
    level 2 if you would like further assistance in determining
    which address space(s) are contributing to the problem of non-
    reusable slots in the ASVT, or see APAR II08563 for more info.
    When contacting level 2, please have the RMID's of the
    following modules available: IEAVEMDL, IEAVESVC AND IEAVFX00.
    At OS/390 r1.3 and later, the XMSE control block in the
    private area of the PCAUTH address space (ASIDx'0002')
    contains the last job name assigned to its corresponding
    address space.  II08563 details how to locate the XMSE
    from the ASCB or ASSB.
      Once the customer has verified that the system is, in fact,
    experiencing problems due to slots being marked non-reusable,
    and once all possible operational measures have been taken to
    minimize the number of address spaces which terminate with
    cross memory connections, the following can be done to
    compensate for the lost slots.  the RSVNONR parameter of the
    IEASYSxx parmlib member should be increased so that it is equal
    to "the number of slots that get marked non-reusable per day"
    times "the maximum number of days between ipls", plus 5 or 10
    "extras". There should be no adverse effects from a modest
    increase of RSVNONR to 100 or 200 from its normal system default
    of 5. Please see OW42868 for possible CSA concerns with
    increasing MAXUSER.
    

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

  • DB2INFO
    

APAR Information

  • APAR number

    II05264

  • Reported component name

    V2 LIB INFO ITE

  • Reported component ID

    INFOV2LIB

  • Reported release

    001

  • Status

    CLOSED USE

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    1991-07-23

  • Closed date

    1991-07-23

  • Last modified date

    2005-03-11

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19N","label":"APARs - OS\/390 environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
13 December 2020