Hi Bill,
have you tried login with ARCCATGP and do a DELETE NSCR ??
HTH, A.Cecilio
2017-08-21 12:21 GMT+01:00 Rodatz, William J <
william.rod...@labor.alabama.gov>:
> Hi,
>
> I want to thank everyone who responded to my inquiry regarding the
> deletion of migrated datasets. It looks like all
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
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.
>
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
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
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 -
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
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
I am glad to help
I am also glad IBM gave at least a way to do this. But I would have preferred
a Facility in the ARC stuff. Easier to remember and see. The use of a GROUP
do to this seems a little kludgy
Lizette
;-D
> -Original Message-
> From: IBM Mainframe Discussion List
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,
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:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.arci000/racf.htm
z/OS DFSMS
z/OS DFSMShsm Implementation and Customization Guide
Implementing DFSMShsm
Authorizing and protecting DFSMShsm commands and resources
DFSMShsm to recall the data set
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
See if you or your job has access to ARCCATGP in (IIRC) the RACF facility class,
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rodatz, William J
Sent: Monday, August 21, 2017 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Removing
Rodatz, William J wrote:
>I wanted to let everyone that I have been able to remove the migrated dataset
>names from the catalog. Lizette Koehler suggested that try using ARCCATGP
>which is a RACF group.
Excellent! I am glad for your part.
I did a little RTFM and came across this snippet in
I wanted to let everyone that I have been able to remove the migrated dataset
names from the catalog. Lizette Koehler suggested that try using ARCCATGP
which is a RACF group. If you are connected to this group you can delete
migrated datasets without first recalling them. I issued the RACF
Classification: Public
I imagine that a vendor product like CIM or TACM could surgically zap the
catalog to remove the entries.
I checked with one of our storage folks, he suggested that the catalog entry
actually has MIGRAT (I've checked that on one of my own migrated datasets with
LISTC),
Hi,
have you tried the TSO DELETE, instead of IDCAMS DELETE? I usually do this
task trying first online (in 3.4 list) and if it doesn't work, with JCL
batch.
I have done it many times, and it works even if you get the HSM error
message, if you have a reasonable recent version of zOS
regards,
Bill,I checked some of our migrated dsns. They have the catalog entry as
MIGRAT1 or MIGRAT2. The status of MIGRAT (folks at FDR please correct me if I
am wrong) indicates that the dsn was archived by FDR.
From: "Usher, Darrold" <014f796d148d-dmarc-requ...@listserv.ua.edu>
To:
Bill, not all the replies were to use DELETE NOSCRATCH. I suggested using the
following sequence:
- Create a new catalog (a throw-away catalog used just for this cleanup)
- REPRO MERGECAT your entries to this new catalog
- Delete the catalog (with RECOVERY)
As far as I know the above steps will
Why not use IEHPROGM to do the uncatalog
//UNCAT EXEC PGM=IEHPROGM
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
UNCATLG DSNAME=name
/*
--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
-Original Message-
From:
Hi,
I want to thank everyone who responded to my inquiry regarding the deletion of
migrated datasets. It looks like all of the responses have suggested using
IDCAMS with the DELETE and NOSCRATCH control statements. I tried that last
week. I ran the job again this morning. Below is the job
If you have access to ARCCATGP then you can do a DEL namehere NOSCRATCH
If you do not, then a RECALL Will be attempted.
See if your security product has ARCCATGP defined and that you can use it.
Then either LOGON to TSO with GROUP ARCCATGP or use a batch job with
GROUP=ARCCATGP
Lizette
>
IIRC, the approach I use is:
- Create a new catalog
- REPRO MERGECAT the entries you want to delete to the new catalog
- Delete the catalog with RECOVERY
Bart
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rodatz, William J
Sent:
As others have said, DEL 'dsname' NSCR will fix you up.
However, I am aware of at least one other product that also uses this
convention.
Be careful!
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rodatz, William J
Sent: Friday,
If you are not running DFHSM are you running any other product that could cause
MIGRAT entries? When CA Disk archives data sets, they are recataloged to
MIGRAT with DEVT(C4C9E2D2). In that case the catalog entry is legitimate.
Bob Longabaugh
CA Technologies
Storage Management
-Original
Did your try DEL 'dsname' NSCR?
Classification: Public Information
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rodatz, William J
Sent: Friday, August 18, 2017 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Removing
Wouldn't a simple IDCAMS DELETE NSCR work?
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rodatz, William J
Sent: Friday, August 18, 2017 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Removing Catalog Entries for Datasets That Do
Hello Everyone,
Recently I discovered some datasets with "MIGRAT" as the volser. These
datasets had been migrated with DFHSM many years ago. My organization is no
longer running the product. I am attempting to remove the dangling catalog
entries which appears to be challenging. The pubs
29 matches
Mail list logo
