IBM Support

II05506: HOW TO DEBUG ABEND878 / ABEND80A RC4 RC8 RC0C RCC RC10 ABEND106 RC0C / RC28 5752SC1CH IGVVSERR

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as canceled.

Error description

  • See informational item BDC000013015 for updated
    information describing how to perform diagnosis of
    local storage shortages using the VERBX VSMDATA 'SUMMARY'
    feature made available through APAR OW35742.
    .
    See informational item BDC000013017 for updated
    information describing how to perform diagnosis of
    global storage shortages using the VERBX VSMDATA 'SUMMARY'
    feature made available through APAR OW35742.
    .
    See informational item BDC000013016 and OW35742 for
    information describing the VSMDATA report enhancements
    available through the VERBX VSMDATA 'SUMMARY' introduced
    in APAR OW35742.
    .
    See informational item BDC000013014 for general information
    about VSM, major control blocks, and frequently asked
    questions.
    .
    
    ***************************************************************
    * NOTE: See info apar II12616 for information on ABEND878 or  *
    *       ABEND80A RC10 getmain failures for storage from the   *
    *       System Region area from address x'1000' to x'5000'.   *
    ***************************************************************
    ABEND878 ABEND80A IPCS SVCDUMP DEBUGGING AIDS FOLLOW.
    FOR ESA430 SEE DIAGxx MEMBER IN IEASYSxx FOR VSMDATA
    ADDL KEYWORD:  INFOPBLIB HOWTO
    

Local fix

Problem summary

  • THE FOLLOWING IS A WAY TO DEBUG ABEND80A / ABEND878 (OUT
      OF STORAGE CONDITIONS).  YOU WILL NEED A DUMP OF THE
      ABEND TO PURSUE.
    -
    -
      1.  TO FIND THE FAILING GETMAIN REQUEST (THE LAST ONE THAT
          WAS ATTEMPTED--REMEMBER THIS GETMAIN IS NOT ALWAYS THE
          CULPRIT, IT CAN BE THE VICTIM OF SOMEONE ELSE EATING
          UP STORAGE) YOU CAN EITHER:
       A. FIND MESSAGE IEA705I (MSGIEA705I) IN THE SYSLOG OUTPUT.
          THE MESSAGE IS FORMATTED IN THE MESSAGES MANUAL.
          THE MESSAGE CONTAINS THE CURRENT ASCB ADDRESS,
          THE DISPATCHED AND INPUTTED TCB ADDRESS, AS WELL
          AS THE SUBPOOL NUMBER AND HOW MANY BYTES THE REQUEST
          WAS FOR.  PLEASE SEE THE MESSAGE MANUAL TO DEBUG.
       B. LOCATED IN THE DUMP IS AN AREA IN THE ENUCLEUS THAT
          VSM PLACES AN UNFORMATTED COPY OF THE MSGIEA705I.
          TO FIND THE LAST GETMAIN REQUESTED, DO THE FOLLOWING
          ON IPCS:
    -
    -
         1. FORMAT THE 'CVT' CONTROL BLOCK BY GOING TO THE
            COMMAND PANEL AND ENTERING 'CVTMAP'
            (FOR MVS/XA) OR 'CBF CVT' (FOR ESA).
    -
         2. AT OFFSET X'10C' INTO THE CVT IS A FIELD CALLED 'QMSG'.
            THIS FIELD POINTS TO AN AREA IN THE EXTENDED NUCLEUS
            THAT VSM USES AS A SAVE AREA FOR ERROR CONDITIONS.  GO
            TO THIS ADDRESS IN THE DUMP.
    -
         3. THE QMSG AREA HAS 'NO' EYECATCHERS, SO YOU
            MUST BE SURE THAT YOU ARE AT THE PROPER LOCATION.
            THE QMSG AREA IS LAID OUT IN THE FOLLOWING MANNER:
    -
      +X'0'=ADDRESS OF NEXT MESSAGE AREA TO BE USED
    -
      +X'C'=REG14 FROM CALLER (IN CASE OF BRANCH ENTRY TO VSM,
                            THIS IS THE CALLER OF VSM)
    -
      +X'12'=ABEND CODE (878, 80A, B78...)
    -
      +X'14'=REASON CODE (10,14,04...)
    -
      +X'15'=FLAGS (DETERMINE IF THIS IS GM OR FM AND SVC OR
             BRANCH ENTRY:
    -
             X'00'=SVC GETMAIN
             X'40'=SVC FREEMAIN
             X'80'=BRANCH ENTRY GETMAIN
             X'C0'=BRANCH ENTRY FREEMAIN
    -
      +X'18'=ASCB ADDRESS OF ASID THAT WAS IN CONTROL AT TIME
             OF REQUEST.
    -
      +X'1C'=THE DISPATCHED TCB ADDRESS
    -
      +X'20'=THE TCB ADDRESS THAT WAS INPUTTED (PASSED) TO VSM .
    -
             (THIS MAY BE DIFFERENT FROM THE DISPATCHED TCB ADDRESS
              IF THE REQUEST WAS A BRANCH ENTRY)
    -
      +X'24'=SUBPOOL NUMBER
    -
      +X'26'=INTERNAL VSM FLAGS (SEE THE MESSAGES MANUAL UNDER
             MSGIEA705I FOR FLAG MEANINGS)
    -
      +X'28'-X'30'= VARIABLE INFORMATION ... MAY BE DIFFERENT
             DEPENDING ON THE FAILURE...SEE THE MSGIEA705I
             INFORMATION IN THE MESSAGES MANUAL FOR THE MEANINGS
             OF THESE FIELDS FOR EACH ABEND DESCRIBED.
    -
    -
    -
      NOW YOU NEED TO DETERMINE IF THE ABEND/CONDITION INDICATE
      A GLOBAL (SQA/CSA) SHORTAGE OR LOCAL (ASID) SHORTAGE.
      GLOBAL DEBUGGING IS GONE THROUGH HERE FIRST, LOCAL
      DEBUGGING FOLLOWS THE CSA DEBUGGING TIPS.
    -
      GLOBAL DEBUGGING:
    -
      ***********************************************************
      * NOTE, YOU NEED TO REMEMBER THAT ONCE THE 'SQA' STORAGE
      IS FILLED, SQA OVERFLOWS INTO CSA.  THIS GOES FOR ABOVE
      THE LINE ALSO, ONCE ESQA FILLS UP, IT OVERFLOWS INTO ECSA.
      SO AN SQA SHORTAGE, MAY ALSO TURN INTO A CSA SHORTAGE IF
      ALL OF THE CSA STORAGE IS EATEN UP BY SQA OVERFLOW.  *
      ***********************************************************
    -
         1.  MAKE SURE YOU HAVE EITHER AN SVCDUMP OF THE ABEND OR
             A SADUMP, HOWEVER A SADUMP TAKEN AFTER THE FACT MAY
             NOT BE OF USE, BECAUSE MANY JOBS/TASKS MAY HAVE BEEN
    -        ALREADY BROUGHT DOWN AND STORAGE CLEANED UP.
    -
         2.  I WILL GO THROUGH THE STEPS ON HOW TO DEBUG USING IPCS,
             IF YOU ARE NOT USING IPCS, PRINT VSMDATA AND PURSUE
             BY HAND.
    -
    -
         3.  GO TO THE COMMAND PANEL ON IPCS AND
             ENTER THE FOLLOWING COMMAND:  'VERBX VSMDATA'
    -
    -
         4.  DO A FIND ON "GDA", THIS IS THE
             GLOBAL DATA AREA, AND THERE IS ONE PER SYSTEM.
    -
             THE GDA+
    -
             X'6C'= CSA  = START OF CSA (BELOW THE LINE)
    -
             X'70'= CSASZ= SIZE OF CSA (BELOW THE LINE)
    -
             X'7C'= ECSA = START OF ECSA (ABOVE THE LINE)
    -
             X'80'= ECSAS= SIZE OF ECSA (ABOVE THE LINE)
    -
         * ->X'8C'= CSACV= THE AMOUNT OF CSA AND/OR ECSA THAT
                    HAS BEEN 'CONVERTED' INTO SQA (OVERFLOW AMOUNT)
    -
             X'90'= SQA  = START OF SQA (BELOW THE LINE)
    -
             X'94'= SQASZ= SIZE OF SQA  (BELOW THE LINE)
    -
             X'98'= ESQA = START OF ESQA (ABOVE THE LINE)
    -
             X'9C'= ESQAS= SIZE OF ESQA  (ABOVE THE LINE)
    -
    -
    -
         * ->CSACV (X'8C') IS A CRITICAL FIELD WHEN DEBUGGING A
             POSSIBLE SQA STORAGE SHORTAGE PROBLEM.   THIS FIELD
             WILL BE NON-ZERO IF THERE IS A POSSIBLE SQA STORAGE
             SHORTAGE PROBLEM.  PROCEED WITH THE FOLLOWING IF
             THERE IS AN SQA STORAGE SHORTAGE PROBLEM:
    -
    -
         5.  DO A FIND ON X'*****' (5 ASTERISKS). EACH TIME YOU
             FIND THIS, YOU WILL FIND THE FOLLOWING MSG: "THE
             AMOUNT OF VIRTUAL STORAGE ALLOCATED TO SUBPOOL X  IS
             XXXX"  WRITE THE TOTALS DOWN.
             THERE ARE 3 SQA SUBPOOLS:
             SP226 (USUALLY USED FOR IOS CONTROL BLOCKS) IS STORAGE
             THAT RESIDES BELOW THE LINE ONLY.  THIS SUBPOOL IS
             USUALLY RELATIVELY  SMALL (X'20000'-X'30000' BYTES).
             SP239 (SUBPOOL IS LARGER THAN SP226) IS USED BY MANY
             PRODUCTS AND STORAGE CAN BE EITHER ABOVE OR
             OR BELOW THE LINE.
             SP245 IS USUALLY THE LARGEST SQA SUBPOOL. AGAIN, THIS
             SUBPOOL IS USED BY MANY PRODUCTS.
             IF YOU CANNOT TELL WHICH SUBPOOL IS THE ONE THAT IS
             ABNORMALLY LARGE, YOU MAY NEED TO TAKE A COMPARISON
             DUMP TO TELL WHAT THE SUBPOOLS ARE NORMALLY LIKE. DO YO
             HAVE AN 'OLD' DUMP WHEN THE SUBPOOLS WERE NOT LARGE?  W
             MAY NEED TO RESORT TO HAVING YOU TAKE A CONSOLE DUMP
             OF AN ASID (MAKING SURE SQA/CSA ARE DUMPED) TO
             COMPARE THE SUBPOOL SIZES IF WE CANNOT TELL WHERE THE
             ABNORMAL GROWTH IS.   IF YOU HAVE ISOLATED THE SUBPOOL,
             THEN CONTINUE TO THE NEXT STEP:
    -
    -
         6.  THE MESSAGE 'THE AMOUNT OF VIRTUAL STORAGE ALLOCATED
             TO SUBPOOL XXX IS XXXXXXXX' FOLLOWS THE CONTROL BLOCKS
             THAT REPRESENT THIS STORAGE.  TO GET TO THE TOP OF THE
             DATA FOR THE SUBPOOL, FIND:
             F 'SUBPOOL XXX' PREV     WHERE THE SUBPOOL NUMBER
             CORRESPONDS TO THE SUBPOOL THAT YOU ARE INTERESTED IN.
             THIS WILL GET YOU BACK TO THE START OF THE VSM CONTROL
    -        BLOCKS THAT REPRESENT THIS SUBPOOL.
    -
         7.  THE STORAGE FOR SQA IS REPRESENTED BY AQATS.
             FIRST GET THE STARTING ADDRESS OF THE 64K REPRESENTED
             BY THE AQAT.  THEN GO TO THE FAR RIGHT, AND OBTAIN THE
             ALLOCATION BITS.  THE BITS ARE A HEX REPRESENTATION
             OF A BIT MAP.  IN MAPPING OUT THE BITS, REMEMBER
             THAT THERE ARE 16 PAGES IN 64K, AND THERE ARE 16
             BITS REPRESENTED BY THE MAP.  TO MAP OUT THE
             ALLOCATED PAGES YOU NEED TO DO THE FOLLOWING:
             OBTAIN THE FIRST AQAT STARTING ADDRESS AND THE
             CORRESPONDING ALLOCATION BITS (EXAMPLE):
    -
             STARTING ADDRESS=E40000     ALLOCATION BITS=2345
             ALLOCATION BITS MAP TO:     0010 0011 0100 0101
    -
             YOU NEED TO NUMBER EACH
             BIT FROM LEFTMOST:          0123 4567 89AB CDEF
    -
             EACH 'ON' BIT, REPRESENTS A PAGE IN USE, IE:
             IN THE PRECEDING EXAMPLE, BIT2 IS ON, SO THE
             2 PAGE IS IN USE.  USING THE START ADDRESS OF X'E40000'
             THE PAGE AT X'E4 2000' IS IN USE,
             BIT 6 IS ALSO ON, SO THE PAGE AT X'E46000' IS IN USE.
             BIT 7 IS ALSO ON, SO THE PAGE AT X'E47000' IS IN USE.
             BIT 9 IS ALSO ON, SO THE PAGE AT X'E49000' IS IN USE.
             AND SO ON...
    -
    -
         8.  TO FIND OUT IF THERE IS ANY FREE STORAGE ON THE
             PAGES SHOWN TO BE IN USE, FIND:
             'ADDRESS QUEUE ORDER'
             THIS WILL GET THEM TO A SECTION UNDERNEATH THE AQAT'S
             CALLED: "DOUBLE FREE ELEMENTS IN ADDRESS QUEUE ORDER
             FOLLOW" .   THE DFE'S ARE ARRANGED IN ASCENDING ORDER
             OF ADDRESS OF FREE STORAGE.   THERE ARE TWO FIELDS
             THAT ARE IMPORTANT:
             AREA (THE START OF THE FREE STORAGE)
             SIZE (THE SIZE OF THE FREE STORAGE)
             GO DOWN THE AREA FIELD UNTIL YOU SEE A NON-ZERO AREA.
             THE AREA COMBINED WITH THE SIZE WILL BE THE START AND
             END OF THE FREE STORAGE.   MAP THIS OUT, BECAUSE YOU
             WILL NEED TO NOTE WHAT IS FREE AS OPPOSED TO WHAT IS
             GETMAINED IN STORAGE AT THIS TIME.
     -
     -
         9.  AFTER YOU HAVE MAPPED OUT MANY OF THE GETMAINED/
             FREEMAINED AREAS OF STORAGE, GO RANDOMLY THROUGH
             THE GETMAINED AREAS IN THE DUMP, LOOKING
             FOR SIMILARITIES IN THE EYECATCHERS IN THE
             GETMAINED AREAS.   IF YOU CANNOT FIND ANY
             SIMILARITIES, YOU MAY NEED TO DO ONE OF THE
             FOLLOWING:
     -
             1.   TAKE A DUMP WHEN THE STORAGE UTILIZATION IS NORMAL
                  AND USE THIS TO COMPARE WITH THE HIGH UTILIZATION
                  DUMP TO SEE WHAT THE DIFFERENCE IN THE STORAGE
                  GETMAINED IS.
     -
             2.   TURN ON THE GETMAIN/FREEMAIN TRACE.
     -
     -
     -
     -
       ---------------------------------------------------
      | C O M M O N  S E R V I C E   A R E A    (CSA)     |
      | __________________________________________________|
    -
    -
      1.  IF THE RETURN CODE DENOTES A CSA PROBLEM, THE
          FOLLOWING SHOULD BE USED TO DEBUG:
     -
     -
      2.  FROM THE TOP OF THE VSMDATA FORMAT (GDA), DO A
          FIND ON:
          'C O M M O N'
          THIS WILL FIND THE 'COMMON SERVICE AREA' WHICH IS THE
          CSA SECTION OF VSMDATA.
     -
     -
      3.  THE FIRST CONTROL BLOCKS FOUND ARE
          FREE BLOCK QUEUE ELEMENTS (FBQE)
          THESE CONTROL BLOCKS ARE PRECEDED BY A 'DUMMY' FBQE
          THAT STARTS WITH "+0 FBQEF ...." AND THE ENTIRE LINE
          OF DATA ON THIS LINE SHOULD BE IGNORED.
          IF THERE IS ANY FREE STORAGE IN ECSA/CSA, THERE
          WILL BE 'FREE BLOCK QUEUE ELEMENTS' LISTED AFTER
          THE DUMMY FBQE.
          IMPORTANT FBQE FIELDS:
          SIZE XXXXXXXX  THE SIZE OF THE FREE CONTIGUOUS STORAGE
          AREA XXXXXXXX  THE STARTING ADDRESS OF THE FREE STORAGE
          IF THE CUSTOMER IS OUT OF CSA, CHANCES ARE
          THERE WON'T BE MANY FBQE'S LISTED.
    -
    -
      4.  FROM HERE, YOU WILL NEED TO MAP OUT EACH SUBPOOL AND
          KEY TO FIND OUT WHO MAY BE EATING UP THE CSA.
          TO FIND EACH SUBPOOL/KEY, HAVE THE CUSTOMER DO A FIND
          ON '*****'.  EACH TIME THEY FIND IT, IT WILL STATE:
          "THE AMOUNT OF VIRTUAL STORAGE ALLOCATED TO SUBPOOL XXX
          KEY XX IS XXXXXXXX"  . WHAT YOU NEED IS THE SUBPOOL,
          THE KEY AND THE AMOUNT OF STORAGE ALLOCATED TO EACH ONE.
          ONCE ALL OF THE CSA SUBPOOLS ARE MAPPED OUT, NOW
          DISCUSS WITH THE CUSTOMER WHICH SUBPOOL LOOKS ABNORMALLY
          LARGE.
    -
    -
      5.  ONCE YOU FIND THE ABNORMALLY LARGE SUBPOOL, YOU NEED
          TO START WITH THE TOP OF THE DATA FOR THAT SUPBOOL (AS
          THE MESSAGE IS AT THE BOTTOM OF THE DATA).
    -
    -
      6.  THE STORAGE IS REPRESENTED BY CONTROL BLOCKS CALLED
          DQE'S AND FQE'S.   EACH DQE DESCRIBES STORAGE ON PAGE
          BOUNDRIES, THE FQE (IF THERE IS ONE) CHAINED TO THE
          DQE SHOWS HOW MUCH OF THE DQE STORAGE IS FREE.
    -
    -
      7.  DQE FIELDS OF IMPORTANCE:
          AREA  XXXXXXXX      THE STARTING ADDRESS OF THE STORAGE
          SIZE  XXXXXXXX      THE SIZE OF THE STORAGE REPRESENTED
    -
    -
      8.  FQE FIELDS OF IMPORTANCE:
          AREA  XXXXXXXX  THE STARTING ADDRESS OF THE FREE STORAGE
          SIZE  XXXXXXXX  THE SIZE OF THE FREE STORAGE
    -
    -
      9.  AFTER MAPPING OUT MANY (RANDOMLY SOMETIMES WORKS)
          DQE/FQE PAIRS, GO INTO STORAGE LOOKING FOR EYECATCHERS.
    -
    -
     10.  LOOK FOR A PATTERN OR EXCESSIVE AMOUNT OF EYECATCHERS.
    -
    -
     11.  IF YOU ARE UNABLE TO FIND A PATTERN, YOU MAY WISH TO
          ASK IBM FOR ASSISTANCE.  YOU MAY NEED TO TAKE ANOTHER
          DUMP OR TURN ON THE GETMAIN / FREEMAIN TRACE.
    -
    -
    ****************************************************************
            L O C A L  (ASID) RELATED DEBUGGING
    ****************************************************************
    IF THE ABEND/REASON CODE INDICATES A PROBLEM WITH VIRTUAL
    STORAGE USAGE IN THE ASID, THE FOLLOWING STEPS NEED TO BE
    TAKEN TO FIND OUT WHERE THE PROBLEM RESIDES:
      1.  HAVE THE CUSTOMER FORMAT OUT THE VSMDATA.
    -
      2.  FIND THE WORD 'LOCAL'
          THIS WILL BE IN THE FOLLOWING STRING OF WORDS:
          "VSM LOCAL DATA AREA (LDA) AT ADDRESS XXXXXXXX"
          IF THE LDA CANNOT BE ACCESSED, THE DUMP DID NOT CONTAIN
          LSQA FOR THE ASID THAT HAD THE STORAGE PROBLEM.
    -
      3.  THE 'LDA' IS THE VSM ANCHOR CONTROL BLOCK FOR ASID'S.
          THERE IS 1 LDA PER ASID.
    -
      4.  THE FOLLOWING FIELDS NEED TO BE OBTAINED EACH TIME
          AN ASID RELATED STORAGE PROBLEM IS DETECTED:
    -
          LDA+
          X'3C'= LDASTRTA  (THE STARTING ADDRESS OF THE PRIVATE AREA
    -
          X'40'= LDASIZA   (THE SIZE OF THE ENTIRE PRIVATE AREA)
    -
          X'4C'= LDAESTRA  (THE STARTING ADDRESS OF EPRIVATE AREA)
    -
          X'50'= LDAESIZA  (THE SIZE OF THE ENTIRE EPRIVATE AREA)
    -
          X'98'= LDACRGTP  (THE CURRENT TOP OF THE REGION (ADDRESS))
    -
          X'9C'= LDAERGTP  (THE CURRENT TOP OF THE EREGION (ADDRESS)
    -
          X'CC'= LDAREGRQ  (THE REGION SIZE REQUESTED BY JOB)
    -
          X'D0'= LDALIMIT  (THE IEALIMIT VALUE FOR BELOW THE LINE)
    -
          X'D4'= LDAVVRG   (THE ADJUSTED REGION SIZE REQUESTED)
    -
          X'D8'= LDAELIM   (THE IEALIMIT VALUE FOR ABOVE THE LINE)
    -
          X'DC'= LDAEVVRG  (THE ADJUSTED EREGION SIZE REQUESTED)
    -
      5.  FIND 'FBQEF' . THIS IS GOING TO BE FOUND
          JUST AFTER 'ADDRESS SPACE REGION DESCRIPTOR DATA
          FOLLOWS'.   THE FBQEF IS ON A 'DUMMY' LINE, AND THIS
          ENTIRE LINE CAN BE IGNORED.
          HOWEVER, IF THERE IS ANY FREE CONTIGUOUS STORAGE IN THE
          ADDRESS SPACE, THERE WILL BE:
          'FREE BLOCK QUEUE ELEMENTS' LISTED UNDERNEATH THIS LINE.
          EACH FBQE REPRESENTS STORAGE ON PAGE BOUNDRIES THAT IS
          FREE.
          THE TWO IMPORTANT FIELDS ARE:
          SIZE (THE SIZE OF THE FREE STORAGE)
          AREA (THE STARTING ADDRESS OF THE FREE STORAGE)
    -
    -
      6.  ONCE ALL OF THIS DATA IS GATHERED, MAP OUT THE STORAGE
          ALLOCATED/FREE BY DRAWING A BOX AND FILLING IN THE
          APPLICABLE ADDRESSES DENOTING WHAT THE ADDRESS SPACE
          LOOKS LIKE AT THIS POINT IN TIME.
    -
      7.  THE NEXT STEP IS TO CORRELATE THIS WITH THE ACTUAL
          OUT OF STORAGE CONDITION THAT IS OCCURRING.
          FOR EXAMPLE, IS THE OUT OF STORAGE CONDITION CAUSED BY
          A LACK OF FREE STORAGE IN THE 'HIGH PRIVATE AREA SUBPOOLS'
          (LSQA/SP229/230/236/237)?   IF SO, WHY?   DOES A SUBPOOL
          HAVE ALL OF THE AVAILABLE STORAGE ALLOCATED TO THEM?
          OR, DOES THE REGION ITSELF HAVE ALL OF THE ALLOCATED
          STORAGE, THUS SQUEEZING OUT THE HIGH PRIVATE SUBPOOLS.
    -
       *** SOMETIMES THIS IS VERY DIFFICULT TO DETERMINE, AND DO NOT
           HESITATE TO CALL LVL2 TO ASSIST ***
    -
      8.  ONCE THE AREA WHERE THE STORAGE PROBLEM HAS BEEN DETERMINE
          (USER REGION VS HIGH PRIVATE), YOU WILL NEED TO GO TO THE
          SUBPOOLS TO FIND OUT WHICH ONE HAS THE STORAGE ALLOCATED T
          IT.
    -
      9.  IF THE PROBLEM IS DETERMINED TO BE THAT A SUBPOOL
          IN THE HIGH PRIVATE AREA HAS EATEN UP ALL OF THE AVAILABLE
          STORAGE, YOU WILL NEED TO GO BACKWARDS IN THE VSMDATA
          TO FIND THE AMOUNT OF STORAGE ALLOCATED TO SP255 (LSQA).
          DO A "F '*****' PREV " .  THIS WILL TAKE THE
          CURSOR BACKWARDS TO FIND THE AMOUNT OF STORAGE ALLOCATED
          TO SP255.
          (THE NORMAL ALLOCATION IN SP255 IS APROXIMATELY X'10000'
          TO X'1F000'.  IF LSQA LOOKS LIKE IT IS ABNORMALLY HIGH,
          YOU WILL NEED TO INTERROGATE THE AQATS/DFE'S IN THE SAME
          MANNER AS YOU WOULD FOR SQA (SEE THE BREAKDOWN OF
          AQAT/DFE IN THE SQA DEBUGGING).
     10.  IF IT IS DETERMINED THAT IT IS NOT LSQA THAT IS CAUSING TH
          STORAGE SHORTAGE SITUATION, HAVE THE CUSTOMER DO REPEAT
          FINDS ON '*****'.   VSM WILL FORMAT OUT THE REST OF THE
          SUBPOOLS UNDER THE TCB THAT WAS CURRENT AT THE TIME OF
          THE GETMAIN INSTRUCTION,  SO YOU WILL FIND MULTIPLES OF
          EACH SUBPOOL.
    -
     11.  YOU WILL NEED TO WRITE EACH AMOUNT DOWN, AND THEN DETERMIN
          WHICH SUBPOOL LOOKS ABNORMALLY LARGE.   ONCE THE SUBPOOL
          IS DETERMINED, YOU WILL NEED TO FIND OUT WHAT THE ALLOCATE
          STORAGE IS COMPRISED OF.
    -
     12.  MAP OUT THE DQE/FQE'S IN THE SAME MANNER AS FOR A CSA
          STORAGE SITUATION (SEE THE CSA DEBUGGING FOR THE MAPPING
          OF DQE/FQE'S) AND GO INTO THE ALLOCATED STORAGE LOOKING
          FOR EYECATCHERS.
    -
     13.  IF NO EYECATCHER IS EVIDENT, YOU MAY NEED TO TURN
          ON THE GM/FM TRACE FOR THE APPLICABLE SUBPOOLS.  SEE
          APAR OY19890 FOR MORE DETAILS ON THE TRACE.
    -
    ****************************************************************
    * NOTE: You need to remember the that private area getmains    *
    *       are satisfied as follows:                              *
    
    
    
    
    
    
    
    *  Attempts to allocate storage whose virtual address is      *
    *  above the 16 megabyte line and the real storage backing it *
    *  is anywhere.                                               *
    *  Attempts to allocate storage whose virtual address is      *
    *  below the 16 megabyte line and the real storage backing    *
    *  it is anywhere.                                            *
    *  Attempts to allocate storage whose virtual address and     *
    *  the real storage backing it is below the 16 megabyte line. *
    ****************************************************************
    

Problem conclusion

  • ADDL KEYWORDS:  RC4 RC8 RCC RC10
    

Temporary fix

Comments

APAR Information

  • APAR number

    II05506

  • Reported component name

    V2 LIB INFO ITE

  • Reported component ID

    INFOV2LIB

  • Reported release

    001

  • Status

    CLOSED CAN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    1991-10-23

  • Closed date

    1991-10-23

  • Last modified date

    2002-04-24

  • 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



Document information

More support for: z/OS family

Software version: 001

Operating system(s): MVS, OS/390, z/OS

Reference #: II05506

Modified date: 24 April 2002