IBM Mainframe Forum

Hi!

I'm facing quite a peculiar situation. Please let me know what other information you need to help me figure out this problem.

There are these 3 datasets, ( HLQ changed throughout the post )
ABCDE.JHH.DUMP.PROD
ABCDE.JDH.DUMP.PROD
ABCDE.JHS.DUMP.PROD

First step of job deletes these dsn via IEFBR14 with disp=mod,delete,delete. These 3 datasets were created by the same job with disp=new,catlg,catlg in the second step. The job failed on E37 on the second step. When I reran job, first step ran OK ( meaning, the datasets were deleted ) but 2nd step failed because “duplicate dsn on Vols TST001, TST002, TST003 for ABCDE.JDH.DUMP.PROD. I deleted dsn via idcams and reran; it went fine.


Step 2 uses CA-Easytrieve Plus and here's the info for the above-mentioned file creation.



How does the dataset exist, if the first step is meant for deleting them, and after the deletion step went fine.

Regards
v1gnesh

You are sending your datasets when writing them to a "pool" of DASD units which are "SYSDA'. That means any one of your files could go on any of a number of disks.

It is likely that on one (or more) of those disks you have some "uncataloged" datasets with the same name, which you have inadvertently created earlier.

Specifying CATLG when already cataloged is one way to create these. Deleting a dataset whilst specifying a volume that it is not on can/used to remove the catalog entry but not delete the dataset from the correct disk.

You have UNIT=SYSDA when creating, and UNIT=DISK when deleting. I don't know if that is giving you the problem, or if you have some stuff left over from earlier runs. If using IEFBR14 to delete, I'd not specify other parameters.

System Programming??? More like SMS.

Are you absolutely sure that the old datasets got deleted? You do not show any output to prove it to us. Also, they may be old, uncataloged, datasets from some failed delete on a previous day that just have not surfaced before now because you were allocating on different volumes. But you have gone and deleted the evidence so I do not think it possible to say what really happened.

NicC wrote:System Programming??? More like SMS.

Are you absolutely sure that the old datasets got deleted? You do not show any output to prove it to us. Also, they may be old, uncataloged, datasets from some failed delete on a previous day that just have not surfaced before now because you were allocating on different volumes. But you have gone and deleted the evidence so I do not think it possible to say what really happened.

Sorry. Mods can please move this to the appropriate topic.

is it possible that in step2, NEW,CATLG,CATLG just uncatalogues the dataset while the job gets an E37-08 ?

EDIT : We recently replaced Mainview SRM with CA - Allocate. If that information is of any use.

Very useful. It means we can tell you that asking here is not going to get you far, as we have no idea how it operated before, nor how CA - Allocate has been installed. The people who know these answers are at your site.

NicC wrote:System Programming??? More like SMS.

Are you absolutely sure that the old datasets got deleted? You do not show any output to prove it to us. Also, they may be old, uncataloged, datasets from some failed delete on a previous day that just have not surfaced before now because you were allocating on different volumes. But you have gone and deleted the evidence so I do not think it possible to say what really happened.

The problem I have posted here is a client's issue. We're providing support, and we're unable to find out the root cause. So when you're saying "I" deleted, its actually the client. The client is a bit dodgy, in the sense that he doesn't want his JCL to be changed. Also, the person uses various DISP parameters for the same dataset in different jobs. So it is really difficult to find out the reason behind the uncatalogued dataset's presence. They haven't been having this problem this long (we recently had a data centre migration; which is why i mentioned that we migrated from Mainview SRM to CA Allocate).

I thought that - if and when the issue happened again, before i delete the datasets, i would give an 'i' in front of the dataset to obtain the creation/reference information. But since its deleted before i can get the information.. i can't do much.

BillyBoyo wrote:Very useful. It means we can tell you that asking here is not going to get you far, as we have no idea how it operated before, nor how CA - Allocate has been installed. The people who know these answers are at your site.

The replacement was 1 year back. The JCLs worked fine back then. The client claims its only after the DC migration that he's facing this problem.

v1gnesh wrote:is it possible that in step2, NEW,CATLG,CATLG just uncatalogues the dataset while the job gets an E37-08 (abnormal end) ?

Does anyone have an answer to this..?

Hi Vignesh,

Is your dasd shared in your environment ? Probably the dataset is uncatalogued in some volume(Mostly in Non-smsed Volume). Could you please post us your SYSPRINT messages ? So , that it will be good enough to diagnose your issue.

Jaggz