Question & Answer
Question
Why doesn't the deletion of members from a link listed PDSE data set reduce the ISPF used pages and the percent utilized statistics for the data set?
Cause
The deletion of PDSE member with active connections does not result in the immediate removal of the member. Instead, the member is placed in a pending delete state.
Answer
A task that accesses a PDSE member for input or output establishes a connection to the member. When a PDSE data set is in the system link list the Link List Lookaside (LLA) address space holds a connection to every member in the PDSE.
When a connected member is deleted or replaced PDSE places that member into a PENDING DELETE state until the task that holds the connection ends or the task itself frees the connection. PDSE uses this mechanism to prevent the deletion of member with one or more active connections. Following member delete or replace processing any job or task that had an existing member connection, for example the LLA address space, continues to access the deleted or replaced member.
Therefore, deleting or replacing all the members of a PDSE library in the active LNKLST places all of the members in the library into a pending delete state.
A subsequent copy of new or updated members into the LNKLST'd PDSE data set would increase the used pages and the percent utilized statistics for the library. This growth is due the space required by the new members in addition to the space used by the old members that are in a PENDING DELETE state.
The SYSPRINT report generated by the IEBPDSE utility program list the number of members that are in a PENDING DELETE state. Sample IEBPDSE JCL follows:
//VALIDATE EXEC PGM=IEBPDSE
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSLIB DD DISP=SHR,DSN=pdse.data.set.name
The space held by members in pending delete state is released when all member connections are dropped. The PDSE processing that performs the space release is aptly referred to as delete_pending_delete processing.
PDSE delete_pending_delete is performed automatically during the first OPEN for OUTPUT for a PDSE data set on an LPAR.
PDSE delete_pending_delete can also be user initiated in one of two methods. The first method is via the IEBPDSE utility's PerformPendingDelete parameter, sample JCL follows:
//VALIDATE EXEC PGM=IEBPDSE,PARM='PERFORMPENDINGDELETE,NOANALYSIS'
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSLIB DD DISP=SHR,DSN=pdse.data.set.name
The second user initiated method is a bit more involved and requires an update to the IGDSMSxx PARMLIB member to include the PDSE_PENDING_DELETE_INTERVAL(nnnn)
This parameter specifies the interval, in minutes, between automatic pending delete processing. This process is intended for installations where PDSEs are left open for output for extended periods of time. As previously stated normal pending delete processing is only performed along with the first open for output on an LPAR,
If an interval of 0 is specified, then parameter driven pending delete processing is not performed.
If an interval, other than 0, is specified, then this interval must be greater than the product of PDSE(1)_LRUCYCLES parameter multiplied by PDSE(1)_LRUTIME parameters. For example, the default value for these parameters is 15 cycles and 60 seconds, which, when multiplied together, equate to 15 minutes. Therefore, if the LRUCYCLES and LRUTIME defaults are taken then the PDSE_PENDING_DELETE_INTERVAL must be 16 or greater.
Note the parameter default is 0. The minimum value is 0, and the maximum is 9999.
Executing an LLA REFRESH after deleting or replacing PDSE members releases the pending delete member connections from the LLA address space. Note that an LLA REFRESH is required across all LPARs that have the data set link listed.
Any long task could hold member connections for an extended period, so having members in a PENDING DELETE state can affect space utilization on any PDSE data set. The PDSE Display CONNECTIONS command can be used determine wither a PDSE data set has any open connections. The format of the command is
D SMS,PDSE,CONNECTIONS,DSN(pdse.data.set.name).
When a connected member is deleted or replaced PDSE places that member into a PENDING DELETE state until the task that holds the connection ends or the task itself frees the connection. PDSE uses this mechanism to prevent the deletion of member with one or more active connections. Following member delete or replace processing any job or task that had an existing member connection, for example the LLA address space, continues to access the deleted or replaced member.
Therefore, deleting or replacing all the members of a PDSE library in the active LNKLST places all of the members in the library into a pending delete state.
A subsequent copy of new or updated members into the LNKLST'd PDSE data set would increase the used pages and the percent utilized statistics for the library. This growth is due the space required by the new members in addition to the space used by the old members that are in a PENDING DELETE state.
The SYSPRINT report generated by the IEBPDSE utility program list the number of members that are in a PENDING DELETE state. Sample IEBPDSE JCL follows:
//VALIDATE EXEC PGM=IEBPDSE
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSLIB DD DISP=SHR,DSN=pdse.data.set.name
The space held by members in pending delete state is released when all member connections are dropped. The PDSE processing that performs the space release is aptly referred to as delete_pending_delete processing.
PDSE delete_pending_delete is performed automatically during the first OPEN for OUTPUT for a PDSE data set on an LPAR.
PDSE delete_pending_delete can also be user initiated in one of two methods. The first method is via the IEBPDSE utility's PerformPendingDelete parameter, sample JCL follows:
//VALIDATE EXEC PGM=IEBPDSE,PARM='PERFORMPENDINGDELETE,NOANALYSIS'
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSLIB DD DISP=SHR,DSN=pdse.data.set.name
The second user initiated method is a bit more involved and requires an update to the IGDSMSxx PARMLIB member to include the PDSE_PENDING_DELETE_INTERVAL(nnnn)
This parameter specifies the interval, in minutes, between automatic pending delete processing. This process is intended for installations where PDSEs are left open for output for extended periods of time. As previously stated normal pending delete processing is only performed along with the first open for output on an LPAR,
If an interval of 0 is specified, then parameter driven pending delete processing is not performed.
If an interval, other than 0, is specified, then this interval must be greater than the product of PDSE(1)_LRUCYCLES parameter multiplied by PDSE(1)_LRUTIME parameters. For example, the default value for these parameters is 15 cycles and 60 seconds, which, when multiplied together, equate to 15 minutes. Therefore, if the LRUCYCLES and LRUTIME defaults are taken then the PDSE_PENDING_DELETE_INTERVAL must be 16 or greater.
Note the parameter default is 0. The minimum value is 0, and the maximum is 9999.
Executing an LLA REFRESH after deleting or replacing PDSE members releases the pending delete member connections from the LLA address space. Note that an LLA REFRESH is required across all LPARs that have the data set link listed.
Any long task could hold member connections for an extended period, so having members in a PENDING DELETE state can affect space utilization on any PDSE data set. The PDSE Display CONNECTIONS command can be used determine wither a PDSE data set has any open connections. The format of the command is
D SMS,PDSE,CONNECTIONS,DSN(pdse.data.set.name).
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG90","label":"z\/OS"},"Component":"5695DF115 - DFSMS\/MVS PDSE AND FAMS","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"2.4;2.2;2.3","Edition":"","Line of Business":{"code":"LOB56","label":"Z HW"}}]
Was this topic helpful?
Document Information
Modified date:
03 September 2021
UID
isg3T1027536