Deleting a dataset wich is not catalogeg



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Re: Deleting a dataset wich is not catalogeg

Postby knv0909 » Fri Mar 01, 2019 3:12 am

Hi guys,
I was surprised to hear that IEHPROGM did not do the job properly :-)
And there is my solution:

//DELETE    EXEC PGM=IEHPROGM
//SYSPRINT DD  SYSOUT=*
//DD1         DD VOL=SER=CFER01,UNIT=DISK,DISP=SHR
//SYSIN      DD  *
  SCRATCH  DSNAME=XFR.FCGT.ADEC,VOL=DISK=CFER01
//
 
knv0909
knv0909
 
Posts: 1
Joined: Wed Nov 14, 2018 1:40 am
Has thanked: 0 time
Been thanked: 0 time

Re: Re: Deleting a dataset wich is not catalogeg

 

Re: Deleting a dataset wich is not catalogeg

Postby expat » Fri Mar 01, 2019 12:31 pm

I believe that if you dump the VVDS - i.e. print it - it will have the name of the catalog that needs to be specified in the IDCAMS DELETE statements
expat
 
Posts: 459
Joined: Sat Jun 09, 2007 3:21 pm
Has thanked: 0 time
Been thanked: 8 times

Re: Deleting a dataset wich is not catalogeg

Postby expat » Fri Mar 01, 2019 12:42 pm

knv0909 wrote:

Hi guys,
I was surprised to hear that IEHPROGM did not do the job properly :-)
And there is my solution:
//DELETE    EXEC PGM=IEHPROGM
//SYSPRINT DD  SYSOUT=*
//DD1         DD VOL=SER=CFER01,UNIT=DISK,DISP=SHR
//SYSIN      DD  *
  SCRATCH  DSNAME=XFR.FCGT.ADEC,VOL=DISK=CFER01
 //
 

I would tend to believe the OP when they say that IEHPROGM didn't work, rather than supply a bog standard example of an IEHPROGM job.

I am pretty sure that I have encountered exactly the same problem in the long and distant past, and eventually resolved it by specifying the relevent catalog name, as stated above.
expat
 
Posts: 459
Joined: Sat Jun 09, 2007 3:21 pm
Has thanked: 0 time
Been thanked: 8 times

Re: Deleting a dataset wich is not catalogeg

Postby Garry F Carroll » Fri Mar 01, 2019 1:58 pm

The IEHPROGM the TS tried was an attempt to UNCATALOG. This might be how the dataset came to be uncataloged in the first place and this will not delete a dataset.

Similarly, the IDCAMS/ADRDSSU jobs failed because they expect the dataset to be cataloged.

Either IEFBR14 with DISP=(OLD,DELETE) of IEHPROGM SCRATCH were what was required.

Garry.
Garry F Carroll
 
Posts: 26
Joined: Wed Sep 19, 2018 8:20 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Deleting a dataset wich is not catalogeg

Postby steve-myers » Fri Mar 01, 2019 9:49 pm

Finally someone pointed out IEHPROGM UNCATALG removes a catalog entry alone. It is equivalent to DELETE xxx NOSCRATCH in IDCAMS or the U line command in ISPF DSLIST (3.4). For us grunts, the ability to do this can (and should be) blocked by the FACILITY / STGADMIN.IGG.DELETE.NOSCRTCH RACF profile or equivalent controls in the other security packages; the capability should be limited to storage administrators. Neophytes like SAMB01 should stay away from storage management tasks or refer the problem to the storage management group.
steve-myers
Global moderator
 
Posts: 2038
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 221 times

Re: Deleting a dataset wich is not catalogeg

Postby samb01 » Mon Mar 04, 2019 6:35 pm

Heelo steve-myers, i am beginners in the storage adlinistrator team and sorry my english isn't very good.
So i anderstood you last post, we may not have the right to uncatlg a dataset ?
Sometimes it's usefull to do that, why should we use RACF to prevent it ?

Or may be i didn't anderstand you...
samb01
 
Posts: 371
Joined: Mon Nov 16, 2009 7:24 pm
Has thanked: 1 time
Been thanked: 0 time

Re: Deleting a dataset wich is not catalogeg

Postby expat » Mon Mar 04, 2019 8:03 pm

Because uncatalog'd datasets cause problems ........... like your own problem where you currently having a problem deleting it.

You have an uncat dsn on a DASD volume, and your overnight batch jobs fails because of a duplicate dsn because it has tried to write the same named dsn onto the volume where it already exists, so it rightly fails. So when you look into the JCL error and initially see that the dataset doesn't exist (because it isn't catalog'd ) it can become confusing. Especially if you restart the failed job and it suddenly works just fine because it has now written to a different DASD volume.

I always used to run a DFdss job every so often when I was a DASD farmer just to look for uncatalog'd datasets, create a backup and then attempting a delete.

The fewer rogue datasets you have, the less problems you have.
expat
 
Posts: 459
Joined: Sat Jun 09, 2007 3:21 pm
Has thanked: 0 time
Been thanked: 8 times

Re: Deleting a dataset wich is not catalogeg

Postby steve-myers » Mon Mar 04, 2019 8:08 pm

samb01 wrote:Heelo steve-myers, i am beginners in the storage adlinistrator team and sorry my english isn't very good.
So i anderstood you last post, we may not have the right to uncatlg a dataset ?
Sometimes it's usefull to do that, why should we use RACF to prevent it ?

Or may be i didn't anderstand you...

You use RACF to prevent UNCATLG to stop neophytes - like you - from doing it and getting into trouble like you have encountered. As you have discovered, deleting an uncataloged system managed data set is somewhat painful.

Don't be too worried about poor English in these boards. As long as we can figure out what you mean, everything is OK. If you don't understand something, ask, and someone will try to explain.

A fundamental requirement of System Managed Storage is the data sets are supposed to be cataloged. Although it's never really been explained, one conceptual advantage of z/OS storage management, it seems to me, is that data sets exist in one name space rather than being chopped up into file systems and directory trees. People coming from toy machines (like Windoze) and baby machines (Unix, Linux and similar systems) are so used to this they don't quite understand why one name space is much better. Yes, z/OS has disk volumes (sort of equivalent to multiple file systems) and tape (which Windoze and *nix hardly believe exists), but in z/OS you can move data sets around without knowing where they exist. This also means the storage management group can move the data around and the end user does not have to fiddle with their JCL or other run procedures to accommodate this movement. I see this as a HUGE improvement over *nix type systems.
steve-myers
Global moderator
 
Posts: 2038
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 221 times

Previous

Return to JCL

 


  • Related topics
    Replies
    Views
    Last post