IBM Mainframe Forum

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

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

knv0909 wrote:

Select all

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.

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.

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.

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...

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.

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.