II07222: DFSMS PDSE AND HFS USABILITY INFORMATION

APAR status

• Closed as canceled.

Error description

• DFSMS PDSE USABILITY INFORMATION (5695DF115).
  GENERAL INFORMATION ON PDSE USAGE:
    See : International Technical Support Centers
        PDSE USAGE GUIDE (GG24-3597 (Redbook)) and
        USING DATA SETS (SC26-4790 or SC26-4922).
   For information on Program Objects (load modules) stored
   in a pdse: See Program Management (SC26-4916)
  PDSE SPACE USAGE ON DASD
    PDSEs are stored on DASD in physical blocks of 4K.
      - So, the BLOCKSIZE is significant only to determine program
        buffer sizes, ie. the application buffers
      - Also, one 4K block of data on DASD contains data for only
        one member.  Members do not share the 4K blocks.  A data
        set containing very small members is not a good candidate
        to be a PDSE, in terms of DASD space usage.
      - There are 6 bytes of control information stored with each
        record written in the 4K physical block.
    Directory blocks are 4K blocks allocated from the same extents
        of the data set as member data.
      - PDSE directories contain more information than PDS
        directories, so they do use more space.
      - Stowing a member may require a new directory block, so an
        ABENDD37 can occur trying to obtain a directory block.
    PDSE reuses blocks of space from members that have been
        updated or deleted.
      - However, this space may not be reclaimed immediately after
        a member is deleted or updated.  If a deleted or updated
        member has a still existing connection from another task
        (or the input DCB from an ISPF edit session), the member
        space will not be reclaimed until the connection is
        released and the data set is opened for output again.
      - An ABENDD37 can occur on a PDSE, indicating it is FULL,
        but another member can still be saved in the data set.
        Recovery processing from a D37 in ISPF closes and reopens
        the data set.  This new open of the data set allows PDSE
        code to reclaim space, so a member can now be saved.
  RELEASING UNUSED SPACE FROM A PDSE:
    One of the advantages of using PDSE over a PDS is the system
    reclaims space automatically whenever a member is deleted or
    replaced and returns the space to the pool of space available
    for allocation to other members of the same PDSE.
     * PDSE excess space that was never used will be released
       when 1) the FREE command is issued in ISPF,
       or 2) when the release parameter (RLSE) is coded on
       the DD statement for an output PDSE data set.
       After HIPER apar OY66089, the PDSE buffer manager partial
       release function will call DADSM to release unused space
       that was never used for PDSE members and was never used
       for directory space.
       When space is allocated and PDSE records are formatted
       for members, the system automatically reuses the "PDSE
       allocated" space whenever a member is replaced or deleted.
       If the highest "PDSE allocated" space or record is smaller
       than the "DADSM allocated" space then this never used space
       will be released during partial release.
       The never used space above high used is NOT released during
       the HSM space management cycle because the partial release
       function is not performed by DFHSM for PDSE data sets.
       When the migration attribute of PARTIAL RELEASE = Y or YI
       is set in the management class, DFHSM will NOT pass ALLDATA
       to DFDSS and tells DFDSS to only dump high used, otherwise
       DFHSM passes ALLDATA to tell DFDSS to dump high allocated.
       With PARTIAL RELEASE = Y or YI, the never used PDSE space
       is NOT dumped by DFDSS.
     * You can reclaim fragmented space caused by member deletes
       and reorganize the data set by copying the PDSE
       to a new PDSE using IEBCOPY or DFDSS COPY or ISPF copy.
     * Deletion of a PDSE member can, in some rare cases, actually
       increase the amount of directory space used by the
       remaining members.
       This can cause the total amount of directory space
       required to be larger after the delete.
       Reference the DFSMS/MVS 1.1 Using Data Sets, SC26-4922.
  PDSE PERFORMANCE CONSIDERATIONS:
   Performance of DCOLLECT of a volume containing 200 data sets
   shows that DCOLLECT clock times and CPU times on PDSE are
   greater than with PDS, up to 10 times greater on CPU time.
    Volume with 200 data sets:
                PDSE          PDS
      CPU        2.92 sec      0.32 sec
      clock     17.0  sec      7.0  sec
   The difference is that on PDS data sets, DCOLLECT gets data
   from the catalog and the format 1 DSCBs and on a PDSE, DCOLLECT
   makes an additional call to IGWFAMS.  DCOLLECT makes one FAMS
   call per data set, however this FAMS call results in a connect
   and disconnect for every data set.  So the additional overhead
   is probably due to the FAMS calls and connecting to data sets.
   These FAMS calls are unavoidable if DCOLLECT must report
   the space allocation of PDSEs.
  
  PDSE VIRTUAL STORAGE USAGE
    Increase ECSA storage allocation a minimum of 10 meg to
      accomadate PDSE usage, and preferably by 30 meg if you have
      very large (in numbers of members) PDSE data sets.
      Some users have increased ECSA by 70 meg to use PDSEs.
    For DFSMS 1.1 increase ESQA storage allocation by 1 meg.
    For DFP 3.2 and 3.3 increase ESQA storage allocation by 600K.
  
    For DFSMS 1.1 data sets allocated on a 3990 cache
    control unit, the first PDSE or non-PDSE data set OPEN
    requires one additional 2K of common ESQA allocated for
    an IGWASAB control block for every address space.
    (With 700 ASID's, thats approximately 1.4 meg of ESQA)
  
    PDSE code obtains approximately 600K of ECSA and 600K of ESQA
      during IPL of a DFSMS 1.1 system.  When PDSE code executes
      additional ECSA and ESQA are obtained.  The storage that is
      obtained is managed and reused by PDSE code.  In DFSMS 1.1
      most of this storage is organized into cell pools. and is
      reused as required by PDSE components.  DFSMS 1.1 includes
      a PDSE compression function that will release inactive cell
      pool extents.
  
    PDSE obtains additional ECSA storage on the first connection
        to each directory and file.  This storage is used for
        control blocks to serialize the directory and files
        between multiple users.
      - The first connection to a directory requires approximately
        800 bytes of ECSA storage for the IGWDIB and other blocks.
      - The first connection to a member requires approximately
        700 bytes of ECSA storage for the IGWFIB and other blocks.
      - The amount of ECSA storage required for PDSE execution
        can be calculated by estimating the number of PDSE data
        sets that are typically active in a system.
        If 100 PDSEs are generally in use, 78K of ECSA storage
        will be required for directories.
        If 1000 PDSE members are generally in use, 683K of ECSA
        storage be required for members.
        Programs commonly used with PDSE, ie. ISPF and IEBCOPY
        have been modified so they do not stay connected to large
        numbers of members, even when working on large PDSEs.
        Applications that do process large numbers of members, but
        have not be modified to work with PDSEs may consume a lot
        of ECSA if they, for example do a BLDL on a large number
        of members and remain connected.  The usage will be 700
        bytes times the number of members connected.
        Programs should be modified to use the BLDL Noconnect and
        STOW Disconnect options of those data management macros.
        ISPF/PDF PTFs that implement these versions of the
  
        BLDL and STOW macros are:
           ISPF/PDF  OY63318  UY93844  3.3
                              UY93845  3.4
                              UY93846  3.5
                     OY63319  UY94422  3.3
                              UY94424  3.5
                     OY64594  UY95907  3.3
                              UY95912  3.4
                              UY95908  3.5
                     OY64593  UY95909  3.3
                              UY95910  3.5
  
        DFP code for BLDL Noconnect is implemented in APAR
           OY31764, which is in the DFP 3.3 base code.
  
        DFP code for STOW Disconnect is implemented in APARs:
           OY58221   UY93213  320
                     UY93214  330
           OY61420   UY93215  110
  
        If an ISPF user is browsing or editing a PDSE, a BLDL is
        done by ISPF for each name on the screen, about 40 names.
        For the duration of the BLDL call these 40 members are
        connected, requiring about 27K of ECSA.  If 25 ISPF users
        could all scroll a member list and get their BLDL executed
        simultaneously, this could require 683K of ECSA.
  
  
  PDSE ATTRIBUTES
    Member count.  PDSE maintains a count of the actual members
        stored in a PDSE.  This count does not include aliases.
      - ISPF retrieves this member count attribute for the data
        set information options in ISPF OPT3.2 and OPT3.4.
        This countdoes not include aliases.  In contrast, ISPF
        reads a PDS directory and counts all of the names in the
        directory, including aliases.
      - In DFP 3.2 and 3.3 the member count can be high by one,
        because the PDSE maintained count still includes the old
        copy of the member that has just been updated or deleted,
        but has not been removed from the data set.
  
    Pages used.  PDSE maintains a count of pages allocated in the
        PDSE.
      - Pages allocated to old copies of members just deleted or
        updated are not immediately reclaimed.  ISPF reports this
        value and uses it to calculate percentage used.
        Since the pages are not always reclaimed immediately, the
        ISPF statistics may still include the pages that will be
        reclaimed.
  
  
  PDSE CROSS SYSTEM SERIALIZATION
    In DFSMS 1.1, in a SYSPLEX environment PDSE code manages cross
    system serialization using XCF.  If a SYSPLEX is not used
    multi-system shared access of PDSEs is serialized via two
    classes of ENQS whose MAJOR NAMES are SYSZIGW0 and SYSZIGW1.
    To ensuer PDSE integrity, ENQS with these MAJOR NAMES must be
    treated as global resources (propagated across all systems in
    the complex) uxing multi-system Global Resource Serialization
    (GRS) or an equivalent function.
  
      You may explicitly code the GRS enqueues in the GRSRNLxx
      member of SYS1.PARMLIB as follows:
          RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(SYSZIGW0)
      The ITSC PDSE usage guide (GG24-3597-00) statements on this
      topic are incorrect.
  
  
  DATA SETS THAT SHOULD NOT BE PDSE
  - SYS1. data sets that are required during IPL of MVS cannot be
      PDSE data sets.  ie. data sets in MSTRJCL00
  - SYS1.PROCLIB is not recommended to be converted to PDSE.
  - A DB2 DBRM (Data Base Resource Module) library is not
    supported as a PDSE.  DB2 attempts to open DBRM data sets
    in a cross memory mode that is not supported by PDSE data
    sets.  The DB2 V4.1 installation manual indicates that
    that DBRM data sets can be PDSEs, but the V5.1 manual has
    been corrected to say that they are not supported.
  
  ****************************************************************
  Recommend installing all High Impact/PERvasive (HIPER)
  service recommendations in the preventive service planning
  install buckets applicable to your release.
  A more current list of recommended DFSMS HIPER PDSE APAR's
  can be obtained by searching the IBM software support
  data base (RETAIN Software Support Facility)
  using DFSMS 1.1.0 release R110 (JDZ1110) search string:
    5695DF115  R110  HIPER
  or using DFSMS 1.2.0 release R1B0 (HDZ11B0) search string:
    5695DF115  R1B0  HIPER
  ****************************************************************
  
  ****************************************************************
  PROBLEM DESCRIPTION:
    The following messages are received
    during allocation of HFS data set:
      msgIGD17040I ERROR IN DADSM PROCESSING
       FOR DATA SET  LEDSMS.OMVS.ROOT
       HISTORIC RETURN CODE IS 200
       DIAGNOSTIC INFORMATION IS 044D0317
      msgIGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING
       RETURN CODE 4 REASON CODE 23.
    Logrec shows ABEND0F4 in IGWLHJIN (UW12850)
    with reason code rsn13010317.
    ( rc044D0317 rsn044D0317 rc23 rc4 )
    ( IGD17040I 044D002A rc044D002A rsn044D002A )
    As a result of errors during 1st HFS create run, now HFS
    create gets msgIGD17040I ERROR IN DADSM PROCESSING w/
    DIAGNOSTIC INFORMATION  044D002A  because residual LADE
    structures were left in the LADE hash table due to incomplete
    error recovery from 1st HFS create.             (MW - 6/10/97)
  PROBLEM CONCLUSION:
    RACF was not active on the system when the HFS data set
    was allocated.  After starting RACF, the HFS data set
    allocated successfully.
    NOTE: If HFS create continues to fail after starting RACF then
          either 1) reIPL; or 2) create HFS on different volume;
          or 3) allocate any data set on volume and then allocate
          HFS on same volume will now have a new TTR of fmt1 DSCB.
  ****************************************************************
   After installing OS390 R2 and defining OMVS HFS data set,
   tried to start OMVS and GFUBMONT invokes DYNALLOC (svc99) to
   allocate the HFS data set and received a non-zero return code
   from dynamic allocation and set GFUBMONT return code '97'
   (EMVSDYNALC) in RTWQ_RET_CODE and results in OMVS msgBPXF002I :
     BPXF002I FILE SYSTEM   OMVS.ROOT   WAS NOT MOUNTED.
              RETURN CODE = 97 ,
              REASON CODE = 035C0002
   The reason code rsn035C0002 in message BPXF002I is the
   DYNALLOC reason code.
   The 1st two bytes is the S99ERROR = 035C  and means an invalid
   parameter list PARM was specified in the text unit and
   the MVS/ESA Authorized Assembler Services Guide, GC28-1467,
   section 26.3.2  Interpreting Error Reason Codes from DYNALLOC
   says message IKJ56231I identifies the text unit in error.
   The text unit consists of fields in which GFUBMONT provides
   information about the DYNALLOC request.
   One way to trap this is to set a SLIP in GFUBMONT just before
   calling CLEANUP when RTWQ_RET_CODE = 97 is detected.
   Customer already had UW28822 fix for OW18387 level of GFUBMONT.
   In this case, BPXF002I was issued because catalog convert did
   not copy all ALIAS's during the OS390 R2 OpenEdition install
   and the OMVS.ROOT  was placed in wrong catalog. (MW - 02/05/97)
  ****************************************************************
  When DCOLLECT encounters an Uncataloged HFS the following LOGREC
  entry will be created:PIDS/5695DF104 RIDS/IGWFAMS RIDS/IGBDCS#L
  PRCS/0000000C. PRCS/2828082A. 2828082A
  ****************************************************************
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• Closing info APAR II07222 so it can be pinned.
  

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