Re: Delete noscratch
Right, this is in SA22-7636-14 and I looked in our -13. Time to update them again. Kees. Burrell, C. Todd , CDC/OCOO/ITSO, CTR [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... From the 1.9 manuals: 54 Explanation: DELETE failed because the data set is being renamed but it has not completed. Programmer Response: Rename the data set with the IDCAMS ALTER command and then delete it. There were vertical bars beside this entry, so it was added via PTF after the manual was updated... C. Todd Burrell Senior z/OS Systems Programmer ITSO (770) 917-8081 (home) (404) 723-2017 (cell) Please visit the ITSO Customer Satisfaction Survey and tell us about your recent experiences with ITSO. This survey is for internal CDC use 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 Mohd Shahrifuddin Sent: Wednesday, March 12, 2008 3:26 AM To: IBM-MAIN@bama.ua.edu Subject: 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 response. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
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 response. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete noscratch
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. All meesages you got. The more information, the better. If I knew the message number I would check it in manual. Without this I don't want to bother. Call me lazy if you want. g BTW: I'm not so lazy. Just checked IDC3009I - no rsn=54. Possibly it's added through a PTF. Or I checked wrong msg. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete noscratch
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-54 Looking at the message manual reason code up to 52. What is reason code 54? Thanks an advance who response. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html IBM has the policy these days to update only the current version of the manual, so if 1.9 is current, the 1.7 manuals are often not updated. However, our 1.9 manual does not have the reason code 54 either, so you could check the 1.10 manuals or look for the APAR that introduced 54. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete noscratch
From the 1.9 manuals: 54 Explanation: DELETE failed because the data set is being renamed but it has not completed. Programmer Response: Rename the data set with the IDCAMS ALTER command and then delete it. There were vertical bars beside this entry, so it was added via PTF after the manual was updated... C. Todd Burrell Senior z/OS Systems Programmer ITSO (770) 917-8081 (home) (404) 723-2017 (cell) Please visit the ITSO Customer Satisfaction Survey and tell us about your recent experiences with ITSO. This survey is for internal CDC use 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 Mohd Shahrifuddin Sent: Wednesday, March 12, 2008 3:26 AM To: IBM-MAIN@bama.ua.edu Subject: 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 response. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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. 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 members confirmed this. Thanks for the inspiration, Rick. Robert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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 members confirmed this. Very new -- works on z/OS 1.8; fails with too many sort fields on 1.6. Thanks for the inspiration, Rick. Me, too. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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 one. Oh, might want to check the Deluxe Check mods on CBT. Think it's got most of these functions covered and a spiffied up version of ISPCALL MACRO. Very dangerous to let the apps folks know about this. They can code up whole applications in nothing flat! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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. 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 members confirmed this. Thanks for the inspiration, Rick. Robert - Always glad to help, in whatever small way I can. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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. Can sort on any displayed field Ascending is default, Descending has been there since day one. Compare: #1.5.3.5 z/OS V1R6.0 ISPF User's Guide Vol I __ 1.5.3.5 Member Selection List Commands ... * SORT [field1[field2]] with: #1.5.3.5 z/OS V1R7.0 ISPF User's Guide Vol I __ 1.5.3.5 Member Selection List Commands ... * | SORT [field1 [A|D] [field2 [A|D]] ] Note the revision bar. My experiment confirms. Perhaps you were benefitting from a local mod. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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 field name. No ISPF mods anyway Figure 51. Sort Fields for Source Libraries Field Sequence Description Name Ascending Member name Lib Ascending Library in concatenation sequence VV Ascending ISPF version number MM Ascending ISPF modification level Created Descending Creation date Changed Descending Date and time last changed Size Descending Current number of records Init Descending Initial number of records Mod Descending Number of modified records ID Ascending Last user -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
Just to add my 2 cents about the DELCATE. In our last DRP (nightmare at ELM STREET d0es not compare) the user used this command while performing a logical restore. However, it clobbered all the aliases. I think if the DELCATE parm is used then the CATALOG parm is required regardless if the 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? Get answers on any topic at Yahoo! Answers. Try it now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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 only do the full volume restore for the tape entry catalog? Then simply define empty user catalogs for the missing disk ones? Eliminate the need to do the delete work. Another thought - would it be simplier (and perhaps quicker) to do full volume restores for all your data instead of selectively restoring only certain datasets? Can the data be organized in a manner that would allow this to happen this way? Test data vs Production data on different volumes, perhaps? Jeffrey Deaver, Engineer, Systems Engineering 651-665-4231 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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. The catalogs are restored along with full pack restores of certain volumes. We then selectively restore our needed disk datasets, almost always to different volsers than in production. Well we generate the IDCAMS delete noscratch statements in about 20 seconds, but then running the acutal IDCAMS deletes takes upwards of 80 minutes to uncatalog 92,000 entries from our largest user catalog. We delete them in alphabetical order. Do you know of anyway I can SPEED up this process?? The job runs unconstrained. It pretty much is the only thing running in the system, it (CATALOG address space) must be doing a huge amount of IO. I though perhaps deleteing things in reverse alphabetical order might improve things but that is just a wild guess. - While I can't speak for reverse order with respect to catalog entries, it makes a HUGE difference in deleting PDS members. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
On Tue, 12 Dec 2006 18:01:48 -0500, Harold Zbiegien wrote: Do you know of anyway I can SPEED up this process?? We do essentially the same thing at our DR tests. I have a REXX EXEC that runs through all the catalogs and verifies datasets in each catalog actually reside on the volume 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 it takes a while to complete this cleanup, it's nowhere near 80 minutes. Maybe splitting it up into smaller chunks ??? I perceive the cleanup process slows down after several thousand deletes as well. But I've got other things going on while that is running, so I don't really care that much. Good Luck. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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 then selectively restore our needed disk datasets, almost always to different volsers than in production. First quesion: if you restore the user catalogs, why do you need to uncatalog the datasets? Restore would effectly uncatalog anything that had changed since the backup Well we generate the IDCAMS delete noscratch statements in about 20 seconds, but then running the acutal IDCAMS deletes takes upwards of 80 minutes to uncatalog 92,000 entries from our largest user catalog. We delete them in alphabetical order. Do you know of anyway I can SPEED up this process?? I find that catalog caching had the largest known effect on catalog operation times. Check out the caching options in the Managing Catalogs manual. It might even be possible to disable caching during the uncatalogs. This might be done by altering the SHR options to make the catalog appear to be unshared during the uncatalogs. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
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 datasets in the catalogs. The catalogs are restored along with full pack restores of certain volumes. We then selectively restore our needed disk datasets, almost always to different volsers than in production. Well we generate the IDCAMS delete noscratch statements in about 20 seconds, but then running the acutal IDCAMS deletes takes upwards of 80 minutes to uncatalog 92,000 entries from our largest user catalog. We delete them in alphabetical order. Do you know of anyway I can SPEED up this process?? The job runs unconstrained. It pretty much is the only thing running in the system, it (CATALOG address space) must be doing a huge amount of IO. I though perhaps deleteing things in reverse alphabetical order might improve things but that is just a wild guess. Harold -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
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 Mainstar/Rocket Software: www.mainstar.com Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Harold Zbiegien Sent: Tuesday, December 12, 2006 6:02 PM 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 just the tape datasets in the catalogs. The catalogs are restored along with full pack restores of certain volumes. We then selectively restore our needed disk datasets, almost always to different volsers than in production. Well we generate the IDCAMS delete noscratch statements in about 20 seconds, but then running the acutal IDCAMS deletes takes upwards of 80 minutes to uncatalog 92,000 entries from our largest user catalog. We delete them in alphabetical order. Do you know of anyway I can SPEED up this process?? The job runs unconstrained. It pretty much is the only thing running in the system, it (CATALOG address space) must be doing a huge amount of IO. I though perhaps deleteing things in reverse alphabetical order might improve things but that is just a wild guess. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: delete noscratch performance at DR
The best way would be to use a product like T-REX. The T-REX SCRUB command will remove entries from your usercatalogs without the need to go thru IDCAMS. Also, T-REX is the only tool on the market that can subtask the SCRUB process. As many as 32 catalogs can be scrubbed simultaneously. Of course, an even better option would be to use the T-REX DRIMPORT command. This will reload your usercatalogs (delete and redefine them, reestablish all ALIAS, etc) and provide you with the option to only restore entries defined to TAPE. Thus, your time to SCRUB is eliminated completely. When your catalogs are reloaded, only your tape entries are restored. Larry Crilley Dino Software, Corp. http://www.dino-software.com/ 412.734.2853 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Harold Zbiegien Sent: Tuesday, December 12, 2006 6:02 PM 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 just the tape datasets in the catalogs. The catalogs are restored along with full pack restores of certain volumes. We then selectively restore our needed disk datasets, almost always to different volsers than in production. Well we generate the IDCAMS delete noscratch statements in about 20 seconds, but then running the acutal IDCAMS deletes takes upwards of 80 minutes to uncatalog 92,000 entries from our largest user catalog. We delete them in alphabetical order. Do you know of anyway I can SPEED up this process?? The job runs unconstrained. It pretty much is the only thing running in the system, it (CATALOG address space) must be doing a huge amount of IO. I though perhaps deleteing things in reverse alphabetical order might improve things but that is just a wild guess. Harold -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
