IBM Mainframe Forum

Its a user dataset and is available in only SMS managed volumes.

The problem was recreated with new,catlg,delete in place of new,catlg,catlg. Still got an E37; but the dataset was not deleted. The second time I ran the job( 1st step is to delete the dataset ), it failed in the first step with

STEP0 OUTFILE2 - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM
IGD17001I DUPLICATE DATA SET NAME ON VOLUME TST002
FOR DATA SET RCIP00S.JDH.DUMP.PROD
IGD17001I DUPLICATE DATA SET NAME ON VOLUME TST003
FOR DATA SET RCIP00S.JDH.DUMP.PROD
IGD17001I DUPLICATE DATA SET NAME ON VOLUME TST001
FOR DATA SET RCIP00S.JDH.DUMP.PROD

How is it that the abnormal termination DISP isn't properly deleting the dataset? It remains uncatalogued on the volume. Here's what i found about the JCL ERROR in STEP0 with MOD,DELETE,DELETE.

“If the system cannot find volume information for the data set on the DD statement, in the catalog, or passed with the data set from a previous step, the system assumes that the data set is being created in this job step.”

Which volume does the catalog point to, if anywhere for this dataset.

Have you done a 3.4 on each of the volumes listed in the error messages to see if the dataset does indeed exist on those volumes.

expat wrote:Which volume does the catalog point to, if anywhere for this dataset.

Have you done a 3.4 on each of the volumes listed in the error messages to see if the dataset does indeed exist on those volumes.

Yes it does exist. The dataset is not catalogued at all. Its available in all 3 volumes, uncatalogued.

ABCDE.JDH.DUMP.PROD TST001
ABCDE.JDH.DUMP.PROD TST002
ABCDE.JDH.DUMP.PROD TST003

What is your JCL for the delete step?

NicC wrote:What is your JCL for the delete step?

Its there in the first post in this thread.

Whoops!
What I do see is that in the delete youa re using UNIT=DISK and in your create step you are using UNIT=SYSDA. These may, or may not, point to the same set of dasd.

Oh, and try using SPACE=(TRK,0) in your delete step. You are deleting a file therefore you do not need any space allocated. Won't affect your problem but it is just neater.

I suggest that you use IDCAMS for deleting datasets, far more reliable than IEFBR14 if your site still uses esoteric DASD pooling, as pointed out by Nic, the unit does differ between the delete and create steps.

Also, you will need to use IDCAMS again to delete the NVR from each of the volumes on which the rogue dataset resides. If the volumes are non SMS managed, then perhaps IEHPROGM may be required.

NicC wrote:Whoops!
What I do see is that in the delete youa re using UNIT=DISK and in your create step you are using UNIT=SYSDA. These may, or may not, point to the same set of dasd.

Oh, and try using SPACE=(TRK,0) in your delete step. You are deleting a file therefore you do not need any space allocated. Won't affect your problem but it is just neater.

We haven't had this problem before, and the same JCL has been in use for years. About the SPACE parm, I completely agree. But the client doesn't like being corrected.

expat wrote:I suggest that you use IDCAMS for deleting datasets, far more reliable than IEFBR14 if your site still uses esoteric DASD pooling, as pointed out by Nic, the unit does differ between the delete and create steps.

Also, you will need to use IDCAMS again to delete the NVR from each of the volumes on which the rogue dataset resides. If the volumes are non SMS managed, then perhaps IEHPROGM may be required.

The volumes are SMS managed. I will ask the client to use IDCAMS to delete the dataset and the NVR entries next time.
Do you think that such a resident NVR entry from before has caused the E37-08, and subsequently the JCL ERROR while deleting the dataset.. ?