Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-22 Thread John Eells

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 the data set.

However, LEGACY is the default, and the data set will be allocated if
LEGACY is in effect.


And that doesn't help the OP who no longer has DFSMShsm.



Entirely true.  I just posted so people would realize NORECALL (and thus 
no allocation) is *not* the default.  Others got him going with DEL 
NOSCR, though.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-21 Thread Tom Marchant
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.
>
>However, LEGACY is the default, and the data set will be allocated if
>LEGACY is in effect.

And that doesn't help the OP who no longer has DFSMShsm.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-21 Thread John Eells
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 allocated if 
LEGACY is in effect.


Allan Staller wrote:

The key is that if the dataset is allocated, HSM will be invoked.

DEL dsn NSCR does not allocate the dataset
IEFBR14 (optional) does not allocate the dataset. This was introduce w/zOS 2.1 
IIRC.
Iehprogm uncatlg will not allocate the dataset.




--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-21 Thread Allan Staller
The key is that if the dataset is allocated, HSM will be invoked.

DEL dsn NSCR does not allocate the dataset
IEFBR14 (optional) does not allocate the dataset. This was introduce w/zOS 2.1 
IIRC.
Iehprogm uncatlg will not allocate the dataset. 

HTH,


It's been a few years since I worked in a shop with DFHSM but I do recall that 
IEHPROGM didn't require a recall but that may have been in the last decade (or 
millennium).

--

-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

Typically for these types of cases, the problem is not the utility being used, 
but that the Entry MIGRAT(1/2) will force a recall.

Only way to get around it is to use the ARCCATGP.  Then IDCAMS, IEHPROGM, etc. 
will work.  You can do the delete noscratch easily then.

So batch job with GROUP=ARCCATGP on the JOBCARD or at TSO LOGON enter ARCCATGP 
in the GROUP field of the logon panel.




::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-21 Thread Dyck, Lionel B. (TRA)
It's been a few years since I worked in a shop with DFHSM but I do recall that 
IEHPROGM didn't require a recall but that may have been in the last decade (or 
millennium).

--
Lionel B. Dyck 
Mainframe Systems 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

Typically for these types of cases, the problem is not the utility being used, 
but that the Entry MIGRAT(1/2) will force a recall.

Only way to get around it is to use the ARCCATGP.  Then IDCAMS, IEHPROGM, etc. 
will work.  You can do the delete noscratch easily then.

So batch job with GROUP=ARCCATGP on the JOBCARD or at TSO LOGON enter ARCCATGP 
in the GROUP field of the logon panel.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Monday, August 21, 2017 7:50 AM
> 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 Systems Programmer - TRA
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of R.S.
> Sent: Monday, August 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 provide his userid, password and the ARCCATGP as 
> the group.
> 
> HTH
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> 
> W dniu 2017-08-21 o 16:36, Allan Staller pisze:
> > My bad, it is *JUST* a group.
> >
> > Lizette provided the info in a later post. Thanks Lizette
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> > Sent: Monday, August 21, 2017 8:41 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
> >
> > Allan Staller wrote:
> >
> >> See if you or your job has access to ARCCATGP in (IIRC) the RACF 
> >> facility class,
> > Sorry, but could you be kind to say what profile in that RACF 
> > FACILITY
> Class?
> >
> > AFAIK, ARCCATGP has no access to any profiles in RACF. (I have 
> > checked that
> in zSecure), I believe, just being a member, you get all the HSM goodies.
> >
> > Thanks in advance.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-21 Thread Lizette Koehler
Typically for these types of cases, the problem is not the utility being used, 
but that the Entry MIGRAT(1/2) will force a recall.

Only way to get around it is to use the ARCCATGP.  Then IDCAMS, IEHPROGM, etc. 
will work.  You can do the delete noscratch easily then.

So batch job with GROUP=ARCCATGP on the JOBCARD or at TSO LOGON enter ARCCATGP 
in the GROUP field of the logon panel.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Monday, August 21, 2017 7:50 AM
> 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 Systems Programmer - TRA
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Monday, August 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 provide his userid, password and the ARCCATGP as the
> group.
> 
> HTH
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> 
> W dniu 2017-08-21 o 16:36, Allan Staller pisze:
> > My bad, it is *JUST* a group.
> >
> > Lizette provided the info in a later post. Thanks Lizette
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> > Sent: Monday, August 21, 2017 8:41 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
> >
> > Allan Staller wrote:
> >
> >> See if you or your job has access to ARCCATGP in (IIRC) the RACF
> >> facility class,
> > Sorry, but could you be kind to say what profile in that RACF FACILITY
> Class?
> >
> > AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that
> in zSecure), I believe, just being a member, you get all the HSM goodies.
> >
> > Thanks in advance.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-21 Thread Dyck, Lionel B. (TRA)
Wouldn't IEHPROGM be easier?


--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, August 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 provide his userid, password and the ARCCATGP as the group.

HTH

--
Radoslaw Skorupka
Lodz, Poland







W dniu 2017-08-21 o 16:36, Allan Staller pisze:
> My bad, it is *JUST* a group.
>
> Lizette provided the info in a later post. Thanks Lizette
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Elardus Engelbrecht
> Sent: Monday, August 21, 2017 8:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist
>
> Allan Staller wrote:
>
>> See if you or your job has access to ARCCATGP in (IIRC) the RACF
>> facility class,
> Sorry, but could you be kind to say what profile in that RACF FACILITY Class?
>
> AFAIK, ARCCATGP has no access to any profiles in RACF. (I have checked that 
> in zSecure), I believe, just being a member, you get all the HSM goodies.
>
> Thanks in advance.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> ::DISCLAIMER::
> 
>
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in 
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on 
> the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the 
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction, 
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written 
> consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please 
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses 
> and other defects.
>
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
h