st 21, 2017 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist
To complement: ARCCATGP is *tricky*.
It is NOT enough to be connected to the group. One has to logon with ARCCATGP
as current connect group.
For TSO one has to provid
t; To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not
> Exist
>
> Wouldn't IEHPROGM be easier?
>
>
> --
> Lionel B. Dyck
> Mainframe
Programmer - TRA
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Monday, August 21, 2017 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not
Exist
Typ
ERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Monday, August 21, 2017 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not
Exist
Typically for these types of cases, the problem is not the utility being used,
but that the Entry MIGRAT
IEFBR14 won't allocate a migrated data set to delete it in a batch job
when IEFBR14_DELMIGDS(NORECALL) is specified in an active ALLOCxx member
of parmlib. Instead, Allocation will call DFSMShsm to (effectively)
HDELETE the data set.
However, LEGACY is the default, and the data set will be al
On Mon, 21 Aug 2017 12:40:50 -0400, John Eells wrote:
>IEFBR14 won't allocate a migrated data set to delete it in a batch job
>when IEFBR14_DELMIGDS(NORECALL) is specified in an active ALLOCxx member
>of parmlib. Instead, Allocation will call DFSMShsm to (effectively)
>HDELETE the data set.
>
>Ho
Tom Marchant wrote:
On Mon, 21 Aug 2017 12:40:50 -0400, John Eells wrote:
IEFBR14 won't allocate a migrated data set to delete it in a batch job
when IEFBR14_DELMIGDS(NORECALL) is specified in an active ALLOCxx member
of parmlib. Instead, Allocation will call DFSMShsm to (effectively)
HDELETE
