Dear Lister,
I try to delete noscratch a dataset and found this error:
Environment z/OS 1.7.
VSAM CATALOG RETURN CODE IS 90 - REASON CODE IS IGG0CLFO-54
Looking at the message manual reason code up to 52. What is reason code 54?
Thanks an advance who response
Mohd Shahrifuddin wrote:
Dear Lister,
I try to delete noscratch a dataset and found this error:
Environment z/OS 1.7.
VSAM CATALOG RETURN CODE IS 90 - REASON CODE IS IGG0CLFO-54
Looking at the message manual reason code up to 52. What is reason code 54?
Mohd,
My hint: provide whole message
"Mohd Shahrifuddin" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Dear Lister,
>
> I try to delete noscratch a dataset and found this error:
>
> Environment z/OS 1.7.
>
> VSAM CATALOG RETURN CODE IS 90 - REASON CODE IS IGG0CLFO-5
ect: Delete noscratch
Dear Lister,
I try to delete noscratch a dataset and found this error:
Environment z/OS 1.7.
VSAM CATALOG RETURN CODE IS 90 - REASON CODE IS IGG0CLFO-54
Looking at the message manual reason code up to 52. What is reason code
54?
Thanks an advance who respo
se only and the results
> will be used to improve business services.
> Anyone working for CDC in any capacity is invited to participate in
our
> survey.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Moh
We have a performance problem I am trying to improve.
When we do our Disaster recovery tests we wind up do a large amount of
delete noscratch against our user catalogs. We basically uncatalog all of
our disk datasets leaving just the tape datasets in the catalogs. The
catalogs are restored
>Do you know of anyway I can SPEED up this process??
Multiple jobs in parallel?
Live with it?
Do you need to do a massive uncatalogue?
Why not just create an 'empty' catalogue?
When in doubt.
PANIC!!
--
For IBM-MAIN subscr
@BAMA.UA.EDU
Subject: delete noscratch performance at DR
We have a performance problem I am trying to improve.
When we do our Disaster recovery tests we wind up do a large amount of
delete noscratch against our user catalogs. We basically uncatalog all
of
our disk datasets leaving just the tape
Are you using DFDSS to restore your files? If so you can use the DELCATE
parameter to have DFDSS perform the DELETE NOSCRATCH for you.
On Tue, 12 Dec 2006 18:45:50 -0500, Richards.Bob <[EMAIL PROTECTED]>
wrote:
>Checkout out the CATSCRUB function of Catalog RecoveryPlus from
>Mai
To: IBM-MAIN@BAMA.UA.EDU
Subject: delete noscratch performance at DR
We have a performance problem I am trying to improve.
When we do our Disaster recovery tests we wind up do a large amount of
delete noscratch against our user catalogs. We basically uncatalog all of
our disk datasets leaving
In <[EMAIL PROTECTED]>, on 12/12/2006
at 06:01 PM, Harold Zbiegien said:
>Do you know of anyway I can SPEED up this process??
Don't use AMS. Check the options mentioned by other posters. If they
don't suit your needs, write a small assembler program that uncatalogs
the data sets directly.
--
volumes are SMS
managed. Please correct me if I am wrong.
Matthew Stitt <[EMAIL PROTECTED]> wrote: Are you using DFDSS to restore your
files? If so you can use the DELCATE
parameter to have DFDSS perform the DELETE NOSCRATCH for you.
-
Any questions
>We basically uncatalog all of our disk datasets
>leaving just the tape datasets in the catalogs.
>The catalogs are restored along with full pack
>restores of certain volumes.
Can you isolate the usercatalogs with disk entries on seperate volumes from
the user catalogs with tape entries and then o
Harold Zbiegien wrote:
We have a performance problem I am trying to improve.
When we do our Disaster recovery tests we wind up do a large amount of
delete noscratch against our user catalogs. We basically uncatalog all
of our disk datasets leaving just the tape datasets in the catalogs
olume the catalog says it
does. If not, I generate a DELETE NOSCRATCH statement for IDCAMS. Deleting
a couple thousand entries is fairly fast. We do have one catalog that
contains 99% stale data, so I end up erasing almost all of the catalog
entries in that catalog - tens of thousands. While i
When we do our Disaster recovery tests we wind up do a large amount of
delete noscratch against our user catalogs. We basically uncatalog all
of our disk datasets leaving just the tape datasets in the catalogs.
The catalogs are restored along with full pack restores of certain
volumes. We
Rick Fochtman wrote (drifting slightly off topic):
>
> While I can't speak for reverse order with respect to
> catalog entries,
> it makes a HUGE difference in deleting PDS members.
>
In a recent note, Robert Bardos said:
> Date: Thu, 14 Dec 2006 12:49:56 +0100
>
> "Wouldn't it make sense then if ISPF allowed us to sort member
> lists in reverse order?" I thought and in fact it does. A quick
> test doing a "sort id name d" on a PDS being used by a bunch of
> team membe
In a message dated 12/14/2006 8:18:37 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Very new -- works on z/OS 1.8; fails with "too many sort fields"
on 1.6.
>>
Maybe it's just the syntax. Can sort on any displayed field Ascending is
default, Descending has been there since day
Robert Bardos wrote:
Rick Fochtman wrote (drifting slightly off topic):
While I can't speak for reverse order with respect to
catalog entries,
it makes a HUGE difference in deleting PDS members.
In a recent note, Ed Finnell said:
> Date: Thu, 14 Dec 2006 09:49:59 EST
>
> In a message dated 12/14/2006 8:18:37 A.M. Central Standard Time,
> [EMAIL PROTECTED] writes:
>
> Very new -- works on z/OS 1.8; fails with "too many sort fields"
> on 1.6.
> >>
> Maybe it's just the syntax. C
In a message dated 12/14/2006 9:54:44 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Note the revision bar. My experiment confirms. Perhaps you
were benefitting from a local mod.
>>
Well semi-hemi-demi. The A and D were added in 1.8 prior to that the A or D
was determined by fi
22 matches
Mail list logo
