II05575: HOW TO DEBUG ABEND822 RC20 5752SC1CH VIRTUAL STORAGE MANAGER VSM

APAR status

• Closed as canceled.

Error description

• DEBUGGING INSTRUCTIONS FOR ABEND822-20 FOLLOW.
  
  Additional Keywords:
       Howto
  

Local fix

Problem summary

• ABEND822-20 DEBUGGING
      THE ABEND IS CAUSED BY SOMEONE EITHER IN A PREVIOUS JOB OR
   JOBSTEP LEAVING FRAGMENTED STORAGE IN THE HIGH PRIVATE AREA
   OF AN ADDRESS SPACE.  THE HIGH PRIVATE STORAGE IS DEFINED AS
   SUBPOOLS, 255 (LSQA, NOT TASK RELATED SO WILL NOT GET FREED
   BY VSM UNTIL THE ADDRESS SPACE IS TERMINATED), 236/237 AND
   229/230.  THE STORAGE WILL BE CHAINED TO A STILL-CURRENT
   TCB IN THE ADDRESS SPACE IF IT IS NOT ASSOCIATED WITH LSQA.
   THE REASON FOR THE ABEND IS VSM IS TRYING TO SATISFY THE
   IEALIMIT VALUE AT JOB OR JOBSTEP INITIALIZATION AND THIS
   VALUE CANNOT BE SATISFIED BY THE CONTIGUOUS FREE STORAGE
   AVAILABLE IN THE PRIVATE AREA.
  -
     TO DEBUG THIS ABEND REQUIRES AN SVCDUMP OF THE ABEND822.
  IN MVS R410 AND ABOVE THIS ABEND IS SLIPPABLE, SO SET THE
  FOLLOWING SLIP TO OBTAIN DOCUMENTATION:
   SLIP SET,COMP=822,A=SVCD,END.
   Note: Please ensure that the following sdata parm is
         either included or already defaulting to:
         (allnuc,sqa,csa,lpa,psa,lsqa,swa,rgn,trt,sum)
   WHEN THE DUMP IS PRODUCED, GO DIRECTLY TO
   STEP 2 TO DEBUG.
  
       FOR MVS/XA ALL RELEASES AND MVS/ESA PRIOR TO REL4:
  STEP 1.  BECAUSE IN THESE RELEASES THE ABEND IS NOT
           SLIPPABLE SET THE SLIP LISTED IN APAR OZ93347
           TO OBTAIN A DUMP OF THE ABEND822 RC20.
  
       ALL MVS RELEASES:
  STEP 2.  ONCE DUMP IS OBTAINED FROM THE ABEND:
     A.    FIND IF THIS IS STEP1 OF A JOB. IF OTHER THAN
        STEP1, DEBUG THE SAME, BUT REMEMBER THAT A PREVIOUS
        JOBSTEP IN THIS JOB LEFT THE STORAGE IN THE ASID,AND
        THIS STORAGE MAY NORMALLY REMAIN THERE FOR THE LIFE
        OF THE ENTIRE JOB.
     B.    IF THE DUMP IS ON IPCS, GO TO THE COMMAND PANEL AND
        ISSUE THE FOLLOWING COMMAND:
             VERBX VSMDATA 'NOGLOBAL'
        or IF IPCS IS NOT AVAILABLE, PRINT VSMDATA VIA PRDMP.
     C.    ONCE VSMDATA IS VISABLE, FIND THE LOCAL DATA AREA
         (LDA) CONTROL BLOCK.  IT IS FORMATTED OUT AND
         YOU WILL NEED TO OBTAIN THE FOLLOWING FIELDS:
              X'3C'=CSTRT    START OF PVT AREA
              X'40'=SIZA     SIZE OF ENTIRE PVT AREA
              X'98'=CRGTP    CURRENT TOP OF REGION ADDRESS
              X'D0'=LIMIT    IEALIMIT VALUE
              X'D4'=VVRG     REGION SIZE
              X'F8'=SMFL     IF 'IEFUSI' IS ACTIVE FOR THIS
                              JOB, THIS WILL CONTAIN
                              THE IEALIMIT VALUE
                                VALUE (DEFAULT IF NONE USED IS
                                'FFFFFFFF') THIS IS FOR BELOW THE
                                16M LINE.
              X'FC'=SMFR     IF IEFUSI IS ACTIVE FOR THIS JOB,
                                THIS WILL CONTAIN THE REGION
                                SIZE (DEFAULT IS X'FFFFFFFF')
                                (BELOW THE 16M LINE VALUE)
        D.     NOW WE NEED TO FIND THE CONTIGUOUS FREE STORAGE.
            THIS IS DONE BY DOING A FIND ON 'FBQEF'.  THIS
            FIELD IS PART OF A HEADER FOR THE 'FREE BLOCK
            QUEUE ELEMENTS' AND SO GIVES US A STARTING
            POINT TO FIND THE FREE CONTIGUOUS STORAGE.
            FROM THE 'FBQEF', GO DOWN TO THE CONTROL BLOCK
            LABELED 'FREE BLOCK QUEUE ELEMENT AT ADDRESS...'
            THIS CONTROL BLOCK IS FORMATTED OUT UNDERNEATH
            THIS STATEMENT, AND WILL SHOW CONTIGUOUS PAGES
            FREE IN THIS ADDRESS SPACE.  THE TWO IMPORTANT
            FIELDS ARE 'AREA' (START OF FREE STORAGE) AND
            SIZE (HOW MUCH IS FREE).   VSM MUST TAKE THE
            REGION IEALIMIT VALUE FROM THE FIRST FREE
            BLOCK QUEUE ELEMENT AMOUNT. FOR EXAMPLE:
            THE IEALIMIT VALUE FOR JOB'X' IS X'710000'
            VSM MUST SATISFY THIS AMOUNT FROM THE FIRST
            FBQE LISTED UNDER THE FBQEF HEADER. IF THE
            FIRST FBQE AREA IS X'6000' AND THE SIZE IS
            '6EB000' WE COULD NOT SATISFY THE IEALIMIT
            VALUE FROM THIS FBQE SO THE ABEND OCCURS.
            IF YOU ADD THE AREA AND THE SIZE OF THE FBQE
            TOGETHER YOU OBTAIN THE 'END' OF THE FREE
            STORAGE.  THE NEXT FBQE LISTED WILL SHOW THE
            NEXT CONTIGUOUS BLOCK OF STORAGE
            IN OUR EXAMPLE, THE IEALIMIT VALUE VSM WAS
            TRYING TO SATISFY WAS X'710000'.  THE REASON
            FOR THE ABEND IS THAT THERE IS ONLY '6EB000'
            BYTES OF STORAGE CONTIGUOUS.  THE NEXT FBQE
            LISTED SHOWED THAT THE NEXT FREE CONTIGUOUS
            BLOCK STARTED AT X'6F2000' FOR X'20000' BYTES.
            (BY ADDING THE AREA AND SIZE OF THE FIRST
            FBQE, WE OBTAIN THE ENDING ADDRESS OF FREE
            STORAGE AT X'6F1000'). SO THIS MEANS THAT THE
            STORAGE STILL GETMAINED IS BETWEEN  X'6F1000'
            AND X'6F2000' AND IS CAUSING THE IEALIMIT
            VALUE NOT TO BE SATISIFIED.
        E.     ONCE THE PAGE(S) THAT CAUSE THE FRAGMENTATION ARE
            FOUND (BY MAPPING OUT THE FBQE'S), THEN WE NEED
            TO FIND OUT WHAT SUBPOOL THESE PAGE(S) BELONG TO.
        F.     FIRST WE CAN SEE IF THE STORAGE IS ALLOCATED TO
            A SUBPOOL OTHER THAN SP255. DO A FIND ON THE
            FIRST ALLOCATED PAGE (FRAGMENTED PAGE).  IF IT IS
            FOUND IT WILL BE IN A 'DQE' CONTROL BLOCK IN THE
            'AREA' FIELD.  THIS IS THE STARTING
            ADDRESS OF THE DESCRIBED STORAGE,
            THEN VERIFY THE SIZE.   IF THERE IS AN FQE
            FORMATTED UNDER THIS DQE, THEN THERE IS
            FRAGMENTED STORAGE WITHIN THIS PAGE.  THE FQE
            REPRESENTS STORAGE THAT IS NOW FREED.
            IN EACH CONTROL BLOCK THERE IS A FIELD CALLED
            AREA AND SIZE.  IN A DQE, THE AREA AND SIZE
            IS THE AMOUNT DESCRIBED ON PAGE BOUNDRIES. FOR
            THE FQE, IT IS THE START AND AMOUNT OF FREE
            STORAGE IN THE PAGE.
            1.  IF THE PAGE IS FOUND IN THIS MANNER,
            GO DOWN THE REST OF THE DQE'S FOR THE SUBPOOL
            IN QUESTION, MAKING SURE THAT THE REST OF THE
            FRAGMENTED STORAGE IS IN THIS SUBPOOL ALSO.
            VERIFY THE SUBPOOL NUMBER BY DOING A FIND ON
            '*****'.  THIS WILL TELL YOU THE SUBPOOL AND
            KEY OF THE STORAGE ALLOCATED.
            2. IF THE PAGE IS NOT FOUND WHEN DOING A FIND
            FOR THE PAGE, THEN IT IS PROBABLY ALLOCATED
            TO SUBPOOL 255 (LSQA).  TO VERIFY THIS, FROM
            FBQE'S, DO A FIND PREVIOUS (F '6F0000' PREV)
            FOR THE PAGE, ROUNDED DOWN TO A 64K BOUNDRY.
            FOR EXAMPLE, FOR AN ALLOCATED PAGE AT X'6F1000',
            F '6F0000' PREV .   THIS SHOULD GET YOU BACK UP
            TO THE AQAT CONTROL BLOCK REPRESENTING THIS 64K
            BLOCK OF STORAGE.   TO DETERMINE IF THE PAGE
            IS ALLOCATED, THE ALLOCATION BITS
            MUST BE MAPPED OUT.
            (1 BIT PER PAGE IN USE.  IF THE BIT IS ON, THE
            PAGE CORROSPONDING TO THE BIT NUMBER (STARTING
            WITH THE LEFTMOST BIT AS BIT'0').  ONCE YOU FIND
            THAT THE BIT IS ON FOR THE PAGE, NOW WE NEED TO
            FIND IF THERE IS ANY FREE STORAGE ON THE PAGE.
            DO A FIND ON 'ADDRESS QUEUE ORDER'. THIS WILL
            BRING YOU DOWN TO THE 'DFE' CONTROL BLOCKS THAT
            REPRESENT FREE STORAGE WITHIN THE PAGES.  GO DOWN
            THE 'AREA' FIELD IN THE DFE'S UNTIL YOU GET DOWN
            TO THE PAGE IN QUESTION.   THE AREA REPRESENTS
            THE STARTING ADDRESS OF THE FREE STORAGE, AND THE
            SIZE, IS HOW MUCH IS FREE.  ONCE THIS IS DONE:
        G.     GO TO THE AREA(S) THAT ARE CAUSING THE
            FRAGMENTATION
            (ONCE THE SUBPOOL(S) ARE FOUND) TO FIND WHAT TYPE
            OF CONTROL BLOCKS ARE IN STORAGE.   REMEMBER:
            1.  VSM SIMPLY SATISFIES GETMAINS FROM THE TOP OF
            PVT DOWN THE ASID FOR THE HIGH PVT SUBPOOLS. THIS
            CALLER GOT DOWN THIS LOW BECAUSE ALL THE STORAGE
            ABOVE HIM WAS ALREADY GETMAINED. THE CALLER
            OF VSM MAY HAVE 'FORGOTTEN' TO DO A FREEMAIN
            FOR THIS ORPHANED STORAGE, OR:
            2.  THE CONTROL BLOCKS THAT YOU SEE MAY BE ASID
            RELATED CONTROL BLOCKS (SO NORMAL TO SEE IN
            STORAGE). THIS MEANS THAT RESEARCH NEEDS TO BE
            DONE AS TO WHAT COULD HAVE CAUSED THESE CONTROL
            BLOCKS TO BE GETMAINED SO LOW IN STORAGE.
            FOR EXAMPLE, THIS STORAGE WAS GETMAINED AND VSM
            GAVE THE CALLER THE 'NEXT AVAILABLE' BLOCK OF
            STORAGE TO SATISFY THEIR GETMAIN. WHAT PROHIBITED
            VSM FROM SATISFYING THE GETMAIN ABOVE THIS VALUE?
            WHAT WAS GETMAINED ABOVE THIS AT THE TIME THIS
            GETMAIN WAS ISSUED.  THIS STORAGE IS NOW PROBABLY
            FREE, SO WE WILL NOT BE ABLE TO IDENTIFY WHAT WAS
            IN STORAGE AT THE TIME OF THE GETMAIN REQUEST.
            IN EITHER CASE, CHECK WITH THE COMPONENT OWNER OF
            THE CONTROL BLOCK(S) TO FIND IF THERE IS A
            POSSIBLE PROBLEM IN FREEMAINING THEIR CONTROL
            BLOCKS.
            ***  NOTE, THE GETMAIN/FREEMAIN TRACE MIGHT BE A
                 USEFUL TOOL IN DETERMINING:
              1.  WHO GETMAINED THE CONTROL BLOCK(S) IN QUESTION
              2.  WHO GETMAINED THE STORAGE ABOVE THIS STORAGE
               MAKING THIS STORAGE ORPHANED SO LOW IN STORAGE.
               FOR MORE INFORMATION ON THE GM/FM TRACE IN MVS/ESA
               SEE APAR OY19890, AND FOR MVS ESA R430 AND ABOVE
               SEE INITIALIZATION AND TUNING GUIDE UNDER 'DIAGxx'
               PARMLIB MEMBER.
  

Problem conclusion

• Additional keywords: MSGIEF085I IEF085I SP229 SP230 SWA
                       JES2INFO VSAMINFO DB2INFO
  

Temporary fix

Comments

APAR Information

• 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