Skip to main content
Status: Declined

This item has not received any further votes for inclusion in the past 12 months since tthe last update.

This suggestion is especially useful for any shops that have a baseline load library connected to something like a CICS region.

We had a situation years ago where an attempt to scratch components from a baseline load library resulted in the 30-job waiting for data sets, needed to be cancelled, and resubmitted with DISP=SHR.  The issue is that the CMN30DEL (as well as CMN30REN) use DISP=OLD to do the deletion (or rename) of members of the target library.

I'm not sure why DISP=OLD is being used in the CMN30DEL and CMN30REN ISPF skeletons, but would a better solution be to use DISP=SHR combined with the CMN$$ENQ skeleton to prevent multiple jobs from updating a given library at the same time?  This would eliminate the issue with the 30-job waiting on data sets because of other resources that are outside of ChangeMan ZMF control.


#DataSetUpdateSerialization
#DataSetContention
#BaselineRipple
Status: Declined

This item has not received any further votes for inclusion in the past 12 months since tthe last update.

This suggestion is especially useful for any shops that have a baseline load library connected to something like a CICS region.

We had a situation years ago where an attempt to scratch components from a baseline load library resulted in the 30-job waiting for data sets, needed to be cancelled, and resubmitted with DISP=SHR.  The issue is that the CMN30DEL (as well as CMN30REN) use DISP=OLD to do the deletion (or rename) of members of the target library.

I'm not sure why DISP=OLD is being used in the CMN30DEL and CMN30REN ISPF skeletons, but would a better solution be to use DISP=SHR combined with the CMN$$ENQ skeleton to prevent multiple jobs from updating a given library at the same time?  This would eliminate the issue with the 30-job waiting on data sets because of other resources that are outside of ChangeMan ZMF control.


#DataSetUpdateSerialization
#DataSetContention
#BaselineRipple

This has been discussed previously with other ZMF customers. The reason for DISP=OLD in steps running CMNDELRN is based on IBM's recommendation to protect against directory corruption when multiple jobs are trying to update the same dataset at the same time. The addition of CMN$$ENQ and changing the allocation to DISP=SHR will only work for jobs running concurrently and submitted by ZMF, not other jobs updating the dataset outside of ZMF.

Some customers have reported directory corruption after changing from DISP=OLD to DISP=SHR.  For now, the product team has decided to leave the skels as coded with DISP=OLD.

We will leave this Idea open for now, in case there are other comments to be added by the community.