ADRDSSU Compatibility
If I have a volume backed up using ADRDSSU 1.11 (DUMP DATASET) is possible to restore it using ADRDSSU 1.10? (backward compatibility) -- Carlos Bodra São Paulo - SP Brazil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU Compatibility
On Fri, 18 Nov 2011 10:26:32 -0200, Carlos Bodra - Pessoal wrote: If I have a volume backed up using ADRDSSU 1.11 (DUMP DATASET) is possible to restore it using ADRDSSU 1.10? (backward compatibility) -- Yes, if the coexistence and fallback PTFs are installed on z/OS 1.10 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2M171/2.1.2.1 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU Compatibility
On 11/18/2011 07:11 AM, Norbert Friemel wrote: On Fri, 18 Nov 2011 10:26:32 -0200, Carlos Bodra - Pessoal wrote: If I have a volume backed up using ADRDSSU 1.11 (DUMP DATASET) is possible to restore it using ADRDSSU 1.10? (backward compatibility) -- Yes, if the coexistence and fallback PTFs are installed on z/OS 1.10 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2M171/2.1.2.1 Norbert Friemel ... But, take note that this backward compatibility does not always exist. It seems that about every ten years or so as tape technology advances IBM decides to raise the block size written by dfdss, first to 64KiB, relatively recently to 256KiB. Be sure to pay attention when this is mentioned in migration notes, because it invariably means that new dump tapes CANNOT be read by back-level versions of dfdss, and you might not have complete control over or knowledge of the update level of dfdss at a recovery site. Although we never had to work around a dfdss failure, our DR tape set always included our current version of stand-alone dfdss, just in case - so we knew we could always restore our emergency restore system (at same software level as production) and didn't have to constantly remember to verify DR site dfdss compatibility that only rarely would be an issue. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU Compatibility
On 11/18/2011 08:18 AM, Norbert Friemel wrote: On Fri, 18 Nov 2011 07:42:34 -0600, Joel C. Ewing wrote: ... But, take note that this backward compatibility does not always exist. It seems that about every ten years or so as tape technology advances IBM decides to raise the block size written by dfdss, first to 64KiB, relatively recently to 256KiB. Be sure to pay attention when this is mentioned in migration notes, because it invariably means that new dump tapes CANNOT be read by back-level versions of dfdss, and you might not have complete control over or knowledge of the update level of dfdss at a recovery site. IBM supports n-2 releases. The 256K blocks were new in z/OS 1.12. There are compatibility PTFs for 1.10 and 1.11 (OA30822). Norbert Friemel I'm glad to know n-2 compatibility is now supported. If that were true long ago when the previous dfdss 64KiB change was made, it certainly wasn't advertised then. The fact that compatibility PTFs for back-level releases are available still doesn't mean you can assume without checking that they are actually installed at some DR site not under your direct control, or that you don't need to be extra careful at such junctures that you have updated all your stand-alone dfdss tapes and have resolved compatibility issues on any back-level systems on site that could conceivably become an issue for local recovery. It's easy to get complacent about issues that are so rare they at most exist for a few months every decade. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU Compatibility
I'm glad to know n-2 compatibility is now supported. If that were true long ago when the previous dfdss 64KiB change was made, it certainly wasn't advertised then. Funny, I thought n-1 was supported for a long time! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU Compatibility
On 11/18/2011 04:15 PM, Ted MacNEIL wrote: I'm glad to know n-2 compatibility is now supported. If that were true long ago when the previous dfdss 64KiB change was made, it certainly wasn't advertised then. Funny, I thought n-1 was supported for a long time! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL Obviously this depends on what is meant by compatibility PTFs. New dfdss versions have always been compatible in reading dumps produced by previous version(s) - changes that invalidated archived dfdss tapes would not be tolerable.. I also can't recall a case other than the 64K block size change where the n-1 version wasn't able to read tapes produced by version n as long as you didn't explicitly use some new features introduced in the new version. The problem with the 64K block change was that you got the new feature by default. I may have missed it, but I don't remember there being a PTF to the old version to allow it to read 64K blocks, at least not at the time we migrated. In some cases the best you can hope for is toleration support for the n-1 version so that it will try to do something reasonable or at least give meaningful warnings or errors if there is some new construct in the dump file related to a new feature in version n that the old version can't fully handle. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
Still on z/OS 1.10. 1.12 is in the works, but due to a problem caused by lack of a maintenance contract, we need to be off of a vendor product before we can convert. Somewhat on topic to this is an interesting discovery I made. If you do a logical dump of a multivolume VSAM KSDS using ADRDSSU, and then do a RESTORE from this with an OUTDYNAM((onevol)), ADRDSSU puts out an ADR390I message about UNMATCHED SIZE and attempt to reallocate the dataset with a new SPACE parameter equal to the sum of the size of all the extents. In our case, this was 7400 cylinders. Which cannot fit on a single 3390-3 volume. So we get some SMS messages about space contraint release being invoked. The LISTCAT on the KSDS now shows a primary space of 7400 cylinders instead of the original value. But all seems well. AT THIS TIME. However, if you then do another logical dump of this KSDS, the restore of that second dump __fails__ with an allocation error about not having any volume with sufficient free space (well, duh! No 3390-3 will ever have 7400 cylinders of free space). In this second case, space constraint release is not invoked. Most weird. If you prealloca! te the output file with the original SPACE parameters and remove the OUTDYNAM, then the RESTORE works correctly and, even better, does not change the space allocation parameters. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Eells Sent: Wednesday, October 12, 2011 12:24 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore If you're on z/OS R12, you might consider using CA Reclaim rather than re-orging KSDSs. McKown, John wrote: I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? John McKown snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ADRDSSU logical dump of VSAM restore
I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
W dniu 2011-10-12 14:41, McKown, John pisze: I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? Yes, it does. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc 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 authorised 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 hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@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.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
A Listcat of the restored file should answer that question. I think Idcams Export/Import is invoked under the covers but I could be mistaken about that. -Original Message- From: McKown, John [mailto:john.mck...@healthmarkets.com] Sent: Wednesday, October 12, 2011 8:42 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU logical dump of VSAM restore I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? What does a LISTCAT of a restored dataset show? The CI and CA split counts are in the statistics output. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
Thanks. The problem is that this is done in a production job and it doesn't have a LISTCAT in it before and after the restore, so I couldn't answer. And updating production JCL is a PITA. Less than a minute to update, 4 days to process the change request (minimum of 4 approvals required). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, October 12, 2011 7:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore A Listcat of the restored file should answer that question. I think Idcams Export/Import is invoked under the covers but I could be mistaken about that. -Original Message- From: McKown, John [mailto:john.mck...@healthmarkets.com] Sent: Wednesday, October 12, 2011 8:42 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU logical dump of VSAM restore I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
If the file had CA/CI splits before the backup and had none after the restore then the file has been re-org'd. Listcat ent(/) all output: STATISTICS REC-TOTAL368 SPLITS-CI--0 --30 REC-DELETED---18 SPLITS-CA--0 ---1 -Original Message- From: Chase, John [mailto:jch...@ussco.com] Sent: Wednesday, October 12, 2011 8:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore -Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? What does a LISTCAT of a restored dataset show? The CI and CA split counts are in the statistics output. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
Are you able to Listcat ent(/) all From ISPF 3.4 screen? -Original Message- From: McKown, John [mailto:john.mck...@healthmarkets.com] Sent: Wednesday, October 12, 2011 9:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore Thanks. The problem is that this is done in a production job and it doesn't have a LISTCAT in it before and after the restore, so I couldn't answer. And updating production JCL is a PITA. Less than a minute to update, 4 days to process the change request (minimum of 4 approvals required). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, October 12, 2011 7:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore A Listcat of the restored file should answer that question. I think Idcams Export/Import is invoked under the covers but I could be mistaken about that. -Original Message- From: McKown, John [mailto:john.mck...@healthmarkets.com] Sent: Wednesday, October 12, 2011 8:42 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU logical dump of VSAM restore I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
Well, yes, but these files are so highly active that they get splits almost instantly. And I needed a right now type answer, not enough time to do a dump/restore-to-another-dsn. I have my answer, thanks to all! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, October 12, 2011 8:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore Are you able to Listcat ent(/) all From ISPF 3.4 screen? -Original Message- From: McKown, John [mailto:john.mck...@healthmarkets.com] Sent: Wednesday, October 12, 2011 9:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore Thanks. The problem is that this is done in a production job and it doesn't have a LISTCAT in it before and after the restore, so I couldn't answer. And updating production JCL is a PITA. Less than a minute to update, 4 days to process the change request (minimum of 4 approvals required). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, October 12, 2011 7:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU logical dump of VSAM restore A Listcat of the restored file should answer that question. I think Idcams Export/Import is invoked under the covers but I could be mistaken about that. -Original Message- From: McKown, John [mailto:john.mck...@healthmarkets.com] Sent: Wednesday, October 12, 2011 8:42 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU logical dump of VSAM restore I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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
Re: ADRDSSU logical dump of VSAM restore
On Wed, 12 Oct 2011 07:41:49 -0500, McKown, John wrote: I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? Reorganized if you restore a logical dump with VALIDATE. VALIDATE is the default. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2U290/2.3.10.5.49?SHELF=dgt2bka0DT=20100623212334CASE= 3. When a data set is restored, the free space in the control areas and control intervals are reset to the values in the catalog entry. You can override the values in the catalog entry by specifying the FREESPACE keyword on the restore. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU logical dump of VSAM restore
If you're on z/OS R12, you might consider using CA Reclaim rather than re-orging KSDSs. McKown, John wrote: I've been asked a question that I can't find the answer to. We are dumping VSAM KSDSes using ADRDSSU in logical dump mode. We then do a RESTORE. Does this reorganized the file, removing CA and CI splits and compressing the data back in physical/logical order? Or is it more like a physical restore of CAs or tracks? John McKown snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
While I am not certain of any magical incantations, if you update the DATACLAS for the existing data sets with the desired EATTR value then, during a DSS COPY, the new allocation of these data sets should be allocated with the new EATTR value you defined. You could also define a new DATACLAS, do a DSS COPY with RENAMEU and have your ACS routines assign the new DATACLAS based on the naming convention. And, as I have already seen mentioned, you can invoke DSS via an API and in EXIT 28 specify the EATTR value to be used for the target allocation. Finally, there is the undesired pre-allocation method. As far as I know these are the only ways to modify EATTR via the use of DSS. Justin Eastman IBM DFSMSdss Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
On 10/10/2011 10:18 AM, Justin Eastman wrote: While I am not certain of any magical incantations, if you update the DATACLAS for the existing data sets with the desired EATTR value then, during a DSS COPY, the new allocation of these data sets should be allocated with the new EATTR value you defined. You could also define a new DATACLAS, do a DSS COPY with RENAMEU and have your ACS routines assign the new DATACLAS based on the naming convention. And, as I have already seen mentioned, you can invoke DSS via an API and in EXIT 28 specify the EATTR value to be used for the target allocation. Finally, there is the undesired pre-allocation method. As far as I know these are the only ways to modify EATTR via the use of DSS. Justin, we updated the DATACLAS for all existing data sets to specify EATTR=OPT. The data sets were not copied to the EAS of the target volume. They were still 'stuck' in track-managed space. This was the reason for my post in the first place. It sounds as if you're saying this is not behaving as expected. I guess we need to open a PMR... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
EATTR only specifies whether a data set is allocated with F8/F9 DSCBs. In order for a data set to be allocated to the cylinder managed space, it must have EATTR = OPT (or EATTR=NS for VSAM as the default is to have F8/F9 DSCBs) and then it must be larger than the defined Break Point Value(BPV) to be allocated to the cylinder managed region. So if the data set is not greater than your BPV it will be allocated to the track managed region. So unless your BPV is less than the size of all the data sets you are trying to get to the cylinder managed region, its working as designed. Justin Eastman IBM DFSMSdss Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
On 10/10/2011 12:07 PM, Justin Eastman wrote: EATTR only specifies whether a data set is allocated with F8/F9 DSCBs. In order for a data set to be allocated to the cylinder managed space, it must have EATTR = OPT (or EATTR=NS for VSAM as the default is to have F8/F9 DSCBs) and then it must be larger than the defined Break Point Value(BPV) to be allocated to the cylinder managed region. So if the data set is not greater than your BPV it will be allocated to the track managed region. So unless your BPV is less than the size of all the data sets you are trying to get to the cylinder managed region, its working as designed. Aha! I had forgotten about the BPV! Thanks for the [re-]education! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Change EATTR for Existing Data Sets with IDCAMS ALTER (Was: Magical Incantations in ADRDSSU)
On 10/6/2011 8:58 AM, Edward Jaffe wrote: http://www.redbooks.ibm.com/redbooks/SG247768/wwhelp/wwhimpl/api.htm?href=4-3-3.htm contains: IBM ITSO Documentation [Snip] To change the EATTR value after a new allocation requires you to run the AMS ALTER command. [Snip] /IBM ITSO Documentation This suggests that IDCAMS ALTER can be used to change the EATTR value for an existing data set. Really? How? I sent this above paragraph to the developer at IBM. He said, Unfortunately EATTR support has not been added to the ALTER command. At one time it was in the plan but fell out. Where did you get this text? We are reexamining this subject for future implementation. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
Maybe you could preallocate it. Probably not what you were looking for though. The other option is an exit 28, Target dataset allocation exit. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
On 10/6/2011 5:13 AM, Mary Anne Matyaz wrote: Maybe you could preallocate it. Probably not what you were looking for though. The other option is an exit 28, Target dataset allocation exit. We want to move literally hundreds--maybe thousands--of data sets into the EAS, so pre-allocating doesn't seem practical. What is the ADRx name of the exit you're suggesting? I could find only ADRUPSWD, ADRUENQ, ADRUIXIT, and ADRREBLK. This is a z/OS 1.13 system. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
Ed, http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.adru000%2Fexit28.htm I suspect preallocate is going to be the answer until DSS supports it. The reason I say this is from the RECLAIMCA doc: You may use data set RESTORE to upgrade your non CA Reclaim enabled data sets to CA Reclaim enabled data sets. To do this, simply preallocate a CA Reclaim enabled data set. That was from https://www-304.ibm.com/support/docview.wss?uid=isg1OA28939 Incidentally, it doesn't appear that FDR has anything either. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
Sorry Ed, I guess I didn't answer your question. This is ADRUIXIT. And, I didn't look at z/os 1.13 manuals...I'm in day four of downloading my serverpak. :( MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
Sorry, ADRUIXIT isn't going to work. It seems the only way to get the UIM is to invoke adrdssu programmatically. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Change EATTR for Existing Data Sets with IDCAMS ALTER (Was: Magical Incantations in ADRDSSU)
http://www.redbooks.ibm.com/redbooks/SG247768/wwhelp/wwhimpl/api.htm?href=4-3-3.htm contains: IBM ITSO Documentation In z/OS V1.10, customers controlled whether VSAM data sets could reside in the EAS by including or excluding EAVs in particular storage groups. For non-SMS managed data sets, the customer controlled the allocation to a volume by specifying a specific VOLSER or esoteric name. This situation is different in z/OS V1.11 because V1.11 provides a new EATTR data set attribute for controlling the allocation of VSAM and non-VSAM data sets in regard to when extended attribute DSCBs and EAS can be used. This new data set is used in AMS DEFINE and ALLOCATE, JCL, dynamic allocation, and data class. IDCAMS AAMS [SIC] ALTER will modify this attribute in existing data sets. There is no JCL override of the current EATTR value for existing data sets. To change the EATTR value after a new allocation requires you to run the AMS ALTER command. The precedence order of EATTR is JCL, LIKE/REFDD, and Data Class. If there is no data class, or the data class has no EATTR value, the processing defaults to the default value based on data set type. The EATTR value resides in the Format 1 and Format 8 DSCBs for VSAM and non-VSAM data sets. It also resides in the primary VVR for VSAM data sets so that it is associated with all components of the VSAM data set. /IBM ITSO Documentation This suggests that IDCAMS ALTER can be used to change the EATTR value for an existing data set. Really? How? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Magical Incantations in ADRDSSU
I need to know the magical incantations necessary to copy (via ADRDSSU) files from a normal-sized DASD volume to the EAS of a target EAV. The existing files are allocated with EATTR=NO. We would like them automatically changed to EATTR=OPT by the copy process so they will reside in the EAS. There does not appear to be any way of specifying a new EATTR value or a new DATACLAS value at copy time. Anyone know how this can be accomplished? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ADRDSSU Restore
Hello List, We are running ZOS 1.12 here, under Z/VM. We want, execute a BACKUP from our production , and restore to another CMS MACHINE. We have a cartridge , with ADRDSSU STANDALONE. If we do a backup from all dasd with the job like this : //ZOSBKP JOB (SUPORTE),'BKP-DB2',CLASS=S, // MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=SYSUID //ZOS112 EXEC PGM=ADRDSSU,REGION=0M //DISKIN DD UNIT=SYSDA,VOL=SER=ZOS112,DISP=SHR //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.ZOS112.D190911, // UNIT=ROBO,LABEL=(0001,SL),DISP=(,CATLG,DELETE), // VOL=(,RETAIN,SER=GR) //SYSINDD * DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN /* //Z2CAT1 EXEC PGM=ADRDSSU,REGION=0M //DISKIN DD UNIT=SYSDA,VOL=SER=Z2CAT1,DISP=SHR //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.Z2CAT1.D190911, // UNIT=ROBO,LABEL=(2,SL),DISP=(,CATLG,DELETE), // VOL=(,RETAIN,SER=GR) //SYSINDD * DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN /* //Z2RES1 EXEC PGM=ADRDSSU,REGION=0M //DISKIN DD UNIT=SYSDA,VOL=SER=Z2RES1,DISP=SHR //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.Z2RES1.D190911, // UNIT=ROBO,LABEL=(3,SL),DISP=(,CATLG,DELETE), // VOL=(,RETAIN,SER=GR) //SYSINDD * DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN /* Then, can we do a restore ? I need use the ADRDSSU COPY option ? Someone know, where I can found a sample for this ? Thanks very much. Sergio Lima Costa São Paulo - Brazil Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da companhia, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect the company's point of view, which is only divulged by authorized personnel. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Guff! ADRDSSU Restore
Sergio, I presume when you say CMS you mean another z/OS instance under z/VM. If this is the case, you can avoid the MVS JCL and use good ole DDR, as long as you have your DASD ready on your target (z/OS) system. Much easier than what you describe below. = Hello List, = = We are running ZOS 1.12 here, under Z/VM. = = We want, execute a BACKUP from our production , and restore to another = CMS MACHINE. = = We have a cartridge , with ADRDSSU STANDALONE. = = If we do a backup from all dasd with the job like this : = = //ZOSBKP JOB (SUPORTE),'BKP-DB2',CLASS=S, = // MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=SYSUID = //ZOS112 EXEC PGM=ADRDSSU,REGION=0M = //DISKIN DD UNIT=SYSDA,VOL=SER=ZOS112,DISP=SHR = //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.ZOS112.D190911, = // UNIT=ROBO,LABEL=(0001,SL),DISP=(,CATLG,DELETE), = // VOL=(,RETAIN,SER=GR) = //SYSINDD * = DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN = /* = //Z2CAT1 EXEC PGM=ADRDSSU,REGION=0M = //DISKIN DD UNIT=SYSDA,VOL=SER=Z2CAT1,DISP=SHR = //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.Z2CAT1.D190911, = // UNIT=ROBO,LABEL=(2,SL),DISP=(,CATLG,DELETE), = // VOL=(,RETAIN,SER=GR) = //SYSINDD * = DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN = /* = //Z2RES1 EXEC PGM=ADRDSSU,REGION=0M = //DISKIN DD UNIT=SYSDA,VOL=SER=Z2RES1,DISP=SHR = //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.Z2RES1.D190911, = // UNIT=ROBO,LABEL=(3,SL),DISP=(,CATLG,DELETE), = // VOL=(,RETAIN,SER=GR) = //SYSINDD * = DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN = /* = = Then, can we do a restore ? = = I need use the ADRDSSU COPY option ? = = Someone know, where I can found a sample for this ? = = Thanks very much. = = Sergio Lima Costa = São Paulo - Brazil = = = = Atenção: Esta mensagem foi enviada para uso exclusivo do(s) = destinatários(s) acima identificado(s), = podendo conter informações e/ou documentos confidencias/privilegiados e = seu sigilo é protegido por = lei. Caso você tenha recebido por engano, por favor, informe o remetente e = apague-a de seu sistema. = Notificamos que é proibido por lei a sua retenção, disseminação, = distribuição, cópia ou uso sem = expressa autorização do remetente. Opiniões pessoais do remetente não = refletem, necessariamente, = o ponto de vista da companhia, o qual é divulgado somente por pessoas = autorizadas. = = Warning: This message was sent for exclusive use of the addressees above = identified, possibly = containing information and or privileged/confidential documents whose = content is protected by law. = In case you have mistakenly received it, please notify the sender and = delete it from your system. = Be noticed that the law forbids the retention, dissemination, = distribution, copy or use without = express authorization from the sender. Personal opinions of the sender do = not necessarily reflect = the company's point of view, which is only divulged by authorized = personnel. = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO = Search the archives at http://bama.ua.edu/archives/ibm-main.html = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RES: Guff! ADRDSSU Restore
Hello, Sorry, forgot said, that the dasd are dedicate, and We can't put our system down. So, need do this in fly with ZOS ONLINE. If not, really DDR is better. Thanks very much for your help. Best Regards. Sergio -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de J. Cassidy Enviada em: segunda-feira, 19 de setembro de 2011 16:18 Para: IBM-MAIN@bama.ua.edu Assunto: Re: Guff! ADRDSSU Restore Sergio, I presume when you say CMS you mean another z/OS instance under z/VM. If this is the case, you can avoid the MVS JCL and use good ole DDR, as long as you have your DASD ready on your target (z/OS) system. Much easier than what you describe below. = Hello List, = = We are running ZOS 1.12 here, under Z/VM. = = We want, execute a BACKUP from our production , and restore to another = CMS MACHINE. = = We have a cartridge , with ADRDSSU STANDALONE. = = If we do a backup from all dasd with the job like this : = = //ZOSBKP JOB (SUPORTE),'BKP-DB2',CLASS=S, = // MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=SYSUID = //ZOS112 EXEC PGM=ADRDSSU,REGION=0M = //DISKIN DD UNIT=SYSDA,VOL=SER=ZOS112,DISP=SHR = //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.ZOS112.D190911, = // UNIT=ROBO,LABEL=(0001,SL),DISP=(,CATLG,DELETE), = // VOL=(,RETAIN,SER=GR) = //SYSINDD * = DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN = /* = //Z2CAT1 EXEC PGM=ADRDSSU,REGION=0M = //DISKIN DD UNIT=SYSDA,VOL=SER=Z2CAT1,DISP=SHR = //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.Z2CAT1.D190911, = // UNIT=ROBO,LABEL=(2,SL),DISP=(,CATLG,DELETE), = // VOL=(,RETAIN,SER=GR) = //SYSINDD * = DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN = /* = //Z2RES1 EXEC PGM=ADRDSSU,REGION=0M = //DISKIN DD UNIT=SYSDA,VOL=SER=Z2RES1,DISP=SHR = //ROBOOUT DD DSN=PROD.SUP.TAPE.LAB.Z2RES1.D190911, = // UNIT=ROBO,LABEL=(3,SL),DISP=(,CATLG,DELETE), = // VOL=(,RETAIN,SER=GR) = //SYSINDD * = DUMP INDD(DISKIN) OUTDD(ROBOOUT) ALLEXCP ALLDATA(*) ADMIN = /* = = Then, can we do a restore ? = = I need use the ADRDSSU COPY option ? = = Someone know, where I can found a sample for this ? = = Thanks very much. = = Sergio Lima Costa = São Paulo - Brazil = = = = Atenção: Esta mensagem foi enviada para uso exclusivo do(s) = destinatários(s) acima identificado(s), = podendo conter informações e/ou documentos confidencias/privilegiados e = seu sigilo é protegido por = lei. Caso você tenha recebido por engano, por favor, informe o remetente e = apague-a de seu sistema. = Notificamos que é proibido por lei a sua retenção, disseminação, = distribuição, cópia ou uso sem = expressa autorização do remetente. Opiniões pessoais do remetente não = refletem, necessariamente, = o ponto de vista da companhia, o qual é divulgado somente por pessoas = autorizadas. = = Warning: This message was sent for exclusive use of the addressees above = identified, possibly = containing information and or privileged/confidential documents whose = content is protected by law. = In case you have mistakenly received it, please notify the sender and = delete it from your system. = Be noticed that the law forbids the retention, dissemination, = distribution, copy or use without = express authorization from the sender. Personal opinions of the sender do = not necessarily reflect = the company's point of view, which is only divulged by authorized = personnel. = = -- = For IBM-MAIN subscribe / signoff / archive access instructions, = send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO = Search the archives at http://bama.ua.edu/archives/ibm-main.html = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a D-65193 Wiesbaden EU Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da companhia, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content
Restore Error - Adrdssu
Hi, I was trying to restore some dataset using the below JCL : 01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B, 02 // REGION=0M,NOTIFY=SYSUID 03 //RESTORE EXEC PGM=ADRDSSU 04 //TAPE DD UNIT=680,DISP=SHR,LABEL=(1,SL), 05 //DSN=BACKUP.USRBKP,VOL=SER=USRBKP 06 //DASD DD UNIT=3390,VOL=SER=CT3T04,DISP=SHR 07 //SYSPRINT DD SYSOUT=* 08 //SYSIN DD * 09 RESTORE INDDNAME(TAPE),OUTDDNAME(DASD) - 10 DATASET(INCLUDE(XXA47467.**)) - 11 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 12 /* 13 //* but i got the below error : 1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 14:32 - RESTORE INDDNAME(TAPE),OUTDDNAME(DASD) - 0007000 DATASET(INCLUDE(XXA47467.**)) - 0008000 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 0008100 ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2011.173 14:32:03 INITIAL SCAN OF USER CONTROL STATEME ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 0ADR006I (001)-STEND(01), 2011.173 14:32:03 EXECUTION BEGINS 0ADR049E (001)-STEND(01), 2011.173 14:47:42 DFSMSDSS FUNCTION TASK ABEND RECOVER CODE=0030 0ADR415W (001)-TDDS (02), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY 0ADR006I (001)-STEND(02), 2011.173 14:47:44 EXECUTION ENDS 0ADR013I (001)-CLTSK(01), 2011.173 14:47:44 TASK COMPLETED WITH RETURN CODE 0008 0ADR012I (SCH)-DSSU (01), 2011.173 14:47:44 DFSMSDSS PROCESSING COMPLETE. HIGHES TASK001 I looked at IBM lookat message : *Explanation:* A function task request that an abend request be recovered and control returned to the function task for cleanup processing before terminating. This message is issued when an abend occurs and the function task abend recovery routine has successfully returned control to the function task. Could'nt figure out the exact syntax error with my JCL. Could anyone please suggest me your idea. Meanwhile I am trying to trace the error behind this. Regards, jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
On Wed, Jun 22, 2011 at 10:32 AM, jagadishan perumal jagadish...@gmail.comwrote: Hi, I was trying to restore some dataset using the below JCL : 01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B, 02 // REGION=0M,NOTIFY=SYSUID 03 //RESTORE EXEC PGM=ADRDSSU 04 //TAPE DD UNIT=680,DISP=SHR,LABEL=(1,SL), 05 //DSN=BACKUP.USRBKP,VOL=SER=USRBKP 06 //DASD DD UNIT=3390,VOL=SER=CT3T04,DISP=SHR 07 //SYSPRINT DD SYSOUT=* 08 //SYSIN DD * 09 RESTORE INDDNAME(TAPE),OUTDDNAME(DASD) - 10 DATASET(INCLUDE(XXA47467.**)) - 11 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 12 /* 13 //* but i got the below error : 1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 14:32 - RESTORE INDDNAME(TAPE),OUTDDNAME(DASD) - 0007000 DATASET(INCLUDE(XXA47467.**)) - 0008000 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 0008100 ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2011.173 14:32:03 INITIAL SCAN OF USER CONTROL STATEME ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 0ADR006I (001)-STEND(01), 2011.173 14:32:03 EXECUTION BEGINS 0ADR049E (001)-STEND(01), 2011.173 14:47:42 DFSMSDSS FUNCTION TASK ABEND RECOVER CODE=0030 0ADR415W (001)-TDDS (02), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY 0ADR006I (001)-STEND(02), 2011.173 14:47:44 EXECUTION ENDS 0ADR013I (001)-CLTSK(01), 2011.173 14:47:44 TASK COMPLETED WITH RETURN CODE 0008 0ADR012I (SCH)-DSSU (01), 2011.173 14:47:44 DFSMSDSS PROCESSING COMPLETE. HIGHES TASK001 I looked at IBM lookat message : *Explanation:* A function task request that an abend request be recovered and control returned to the function task for cleanup processing before terminating. This message is issued when an abend occurs and the function task abend recovery routine has successfully returned control to the function task. Could'nt figure out the exact syntax error with my JCL. Could anyone please suggest me your idea. Meanwhile I am trying to trace the error behind this. Regards, jags Looks like the CODE=0030 may be associated with an open/close error. Are there any further messages in the JES2 JESMSGLG for this job related to an abend. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
JESMSGLG : 15.10.21 JOB02012 WEDNESDAY, 22 JUN 2011 15.10.21 JOB02012 IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB. 15.10.21 JOB02012 IRR011I SECLABEL SYSHIGH IS ASSIGNED TO THIS JOB. 15.10.22 JOB02012 ICH70001I IBMUSER LAST ACCESS AT 14:32:03 ON WEDNESDAY, JUNE 15.10.22 JOB02012 $HASP373 RESTORE$ STARTED - INIT 6- CLASS T - SYS CTS3 15.10.22 JOB02012 IEF403I RESTORE$ - STARTED - TIME=15.10.22 15.10.22 JOB02012 *IEF233A M 0680,USRBKP,,RESTORE$,STEP1 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK 15.19.27 JOB02012 IEF234E K 0680,USRBKP,PVT,RESTORE$,STEP1 15.19.27 JOB02012 IEF404I RESTORE$ - ENDED - TIME=15.19.27 15.19.27 JOB02012 $HASP395 RESTORE$ ENDED On Wed, Jun 22, 2011 at 3:32 PM, Jim McAlpine jim.mcalp...@gmail.comwrote: On Wed, Jun 22, 2011 at 10:32 AM, jagadishan perumal jagadish...@gmail.comwrote: Hi, I was trying to restore some dataset using the below JCL : 01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B, 02 // REGION=0M,NOTIFY=SYSUID 03 //RESTORE EXEC PGM=ADRDSSU 04 //TAPE DD UNIT=680,DISP=SHR,LABEL=(1,SL), 05 //DSN=BACKUP.USRBKP,VOL=SER=USRBKP 06 //DASD DD UNIT=3390,VOL=SER=CT3T04,DISP=SHR 07 //SYSPRINT DD SYSOUT=* 08 //SYSIN DD * 09 RESTORE INDDNAME(TAPE),OUTDDNAME(DASD) - 10 DATASET(INCLUDE(XXA47467.**)) - 11 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 12 /* 13 //* but i got the below error : 1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 14:32 - RESTORE INDDNAME(TAPE),OUTDDNAME(DASD) - 0007000 DATASET(INCLUDE(XXA47467.**)) - 0008000 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 0008100 ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2011.173 14:32:03 INITIAL SCAN OF USER CONTROL STATEME ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 0ADR006I (001)-STEND(01), 2011.173 14:32:03 EXECUTION BEGINS 0ADR049E (001)-STEND(01), 2011.173 14:47:42 DFSMSDSS FUNCTION TASK ABEND RECOVER CODE=0030 0ADR415W (001)-TDDS (02), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY 0ADR006I (001)-STEND(02), 2011.173 14:47:44 EXECUTION ENDS 0ADR013I (001)-CLTSK(01), 2011.173 14:47:44 TASK COMPLETED WITH RETURN CODE 0008 0ADR012I (SCH)-DSSU (01), 2011.173 14:47:44 DFSMSDSS PROCESSING COMPLETE. HIGHES TASK001 I looked at IBM lookat message : *Explanation:* A function task request that an abend request be recovered and control returned to the function task for cleanup processing before terminating. This message is issued when an abend occurs and the function task abend recovery routine has successfully returned control to the function task. Could'nt figure out the exact syntax error with my JCL. Could anyone please suggest me your idea. Meanwhile I am trying to trace the error behind this. Regards, jags Looks like the CODE=0030 may be associated with an open/close error. Are there any further messages in the JES2 JESMSGLG for this job related to an abend. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
On Wed, Jun 22, 2011 at 11:06 AM, jagadishan perumal jagadish...@gmail.comwrote: JESMSGLG : 15.10.21 JOB02012 WEDNESDAY, 22 JUN 2011 15.10.21 JOB02012 IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB. 15.10.21 JOB02012 IRR011I SECLABEL SYSHIGH IS ASSIGNED TO THIS JOB. 15.10.22 JOB02012 ICH70001I IBMUSER LAST ACCESS AT 14:32:03 ON WEDNESDAY, JUNE 15.10.22 JOB02012 $HASP373 RESTORE$ STARTED - INIT 6- CLASS T - SYS CTS3 15.10.22 JOB02012 IEF403I RESTORE$ - STARTED - TIME=15.10.22 15.10.22 JOB02012 *IEF233A M 0680,USRBKP,,RESTORE$,STEP1 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK 15.19.27 JOB02012 IEF234E K 0680,USRBKP,PVT,RESTORE$,STEP1 15.19.27 JOB02012 IEF404I RESTORE$ - ENDED - TIME=15.19.27 15.19.27 JOB02012 $HASP395 RESTORE$ ENDED the following message is telling you that the program cannot read the TAPE1 input - 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK are you sure that this tape was created using ADRDSSU. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
Yes, but i have a doubt. In our shop Dasd volumes are visible on both the LPARS. The datasets which were backed up were used to reside to on the volumes which were visible on the target lpar. Is this could be a problem, if it is so is it appreciable to make the the volumes offline in the target LPAR which we are trying to restore . On Wed, Jun 22, 2011 at 4:00 PM, Jim McAlpine jim.mcalp...@gmail.comwrote: On Wed, Jun 22, 2011 at 11:06 AM, jagadishan perumal jagadish...@gmail.comwrote: JESMSGLG : 15.10.21 JOB02012 WEDNESDAY, 22 JUN 2011 15.10.21 JOB02012 IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB. 15.10.21 JOB02012 IRR011I SECLABEL SYSHIGH IS ASSIGNED TO THIS JOB. 15.10.22 JOB02012 ICH70001I IBMUSER LAST ACCESS AT 14:32:03 ON WEDNESDAY, JUNE 15.10.22 JOB02012 $HASP373 RESTORE$ STARTED - INIT 6- CLASS T - SYS CTS3 15.10.22 JOB02012 IEF403I RESTORE$ - STARTED - TIME=15.10.22 15.10.22 JOB02012 *IEF233A M 0680,USRBKP,,RESTORE$,STEP1 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK 15.19.27 JOB02012 IEF234E K 0680,USRBKP,PVT,RESTORE$,STEP1 15.19.27 JOB02012 IEF404I RESTORE$ - ENDED - TIME=15.19.27 15.19.27 JOB02012 $HASP395 RESTORE$ ENDED the following message is telling you that the program cannot read the TAPE1 input - 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK are you sure that this tape was created using ADRDSSU. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
jagadishan perumal wrote: 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK Do a TAPEMAP on that volume and post the result here. I really doubt your tape was written correctly in the backup stage. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
Hi, The back up went fine with CC=0. Below is my JCL //BACKUP$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=T, // REGION=5M,NOTIFY=SYSUID //DUMPDS EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //DASD1 DD VOL=SER=LDSN16,UNIT=3390,DISP=SHR //DASD2 DD VOL=SER=LDSN15,UNIT=3390,DISP=SHR //DASD3 DD VOL=SER=LDSN14,UNIT=3390,DISP=SHR //DASD4 DD VOL=SER=PUBLB3,UNIT=3390,DISP=SHR //DASD5 DD VOL=SER=PUBLB4,UNIT=3390,DISP=SHR //DASD6 DD VOL=SER=LDSN18,UNIT=3390,DISP=SHR //DASD7 DD VOL=SER=LPRJ20,UNIT=3390,DISP=SHR //DASD8 DD VOL=SER=LPRJ15,UNIT=3390,DISP=SHR //DASD9 DD VOL=SER=LPRJ16,UNIT=3390,DISP=SHR //DASD10 DD VOL=SER=LPRJ14,UNIT=3390,DISP=SHR //DASD11 DD VOL=SER=LIB001,UNIT=3390,DISP=SHR //DASD12 DD VOL=SER=LPRJ19,UNIT=3390,DISP=SHR //DASD13 DD VOL=SER=FREE01,UNIT=3390,DISP=SHR //DASD14 DD VOL=SER=FREE02,UNIT=3390,DISP=SHR //DASD15 DD VOL=SER=LPRJ18,UNIT=3390,DISP=SHR //DASD16 DD VOL=SER=LPRJ10,UNIT=3390,DISP=SHR //DASD17 DD VOL=SER=LPRJ17,UNIT=3390,DISP=SHR //TAPE1DD DSN=BACKUP.USRBKP,DISP=(NEW,CATLG), // UNIT=680,LABEL=(1,SL),VOL=SER=USRBKP //SYSIN DD * DUMP LIDD(DASD1 DASD2 DASD3 DASD4 DASD5 DASD6 DASD7 DASD8 DASD9 - DASD10 DASD11 DASD12 DASD13 DASD14 DASD15 DASD16 DASD17)- OUTDDNAME(TAPE1) - DS(INCL(XXA47467.** - U195530.** - U251034.** - U251050.** )) /* SYSPRINT : PAGE 0001 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 DUMP LIDD(DASD1 DASD2 DASD3 DASD4 DASD5 DASD6 DASD7 DASD8 DASD9 - DASD10 DASD11 DASD12 DASD13 DASD14 DASD15 DASD16 DASD17)- OUTDDNAME(TAPE1) - DS(INCL(XXA47467.** - U195530.** - U251034.** - U251050.** )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' ADR109I (R/I)-RI01 (01), 2011.172 18:54:06 INITIAL SCAN OF USER CONTROL STATEMEN ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2011.172 18:54:06 EXECUTION BEGINS ADR788I (001)-DIVSM(03), PROCESSING COMPLETED FOR CLUSTER U195530.IN.KSDS, 3 REC ADR801I (001)-DTDSC(01), DATA SET FILTERING IS COMPLETE. 182 OF 182 DATA SETS WE FOR OTHER REASONS. ADR454I (001)-DTDSC(01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED U195530.SPFLOG1.LIST U251050.SQL.OUTPUT U251034.PUNCH.DEPLUTI2 U251050.DSNUQUI.CNTL U195530.TRAIL.PS U195530.XEROX.PS U195530.XEROX13.PS U251034.PUNCH.DEPLUTI3 U251034.SQL.UTILITY U195530.PROCLIB U195530.JCLLIB U195530.CONTROL U195530.SAM.PS U195530.NEW.PS U251050.LOAD.EUTIL U195530.SPF1.LIST U195530.IN.PS U251034.UNLOAD.DEPLUTI PAGE 0002 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 U251050.UNLOAD.DEPTUTI U251050.UNLOAD.EMPLUTI U195530.SPFTEMP0.CNTL CLUSTER NAME U195530.IN.KSDS 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 CATALOG NAME CATALOG.CTSUSER.VZ16CAT COMPONENT NAME U195530.IN.KSDS.DATA COMPONENT NAME U195530.IN.KSDS.INDEX CLUSTER NAME U195530.MVS.RRDS CATALOG NAME CATALOG.CTSUSER.VZ16CAT COMPONENT NAME U195530.MVS.RRDS.DATA ADR006I (001)-STEND(02), 2011.172 18:57:08 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2011.172 18:57:08 TASK COMPLETED WITH RETURN CODE ADR012I (SCH)-DSSU (01), 2011.172 18:57:08 DFSMSDSS PROCESSING COMPLETE. HIGHEST Regards, Jags On Wed, Jun 22, 2011 at 4:12 PM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: jagadishan perumal wrote: 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK Do a TAPEMAP on that volume and post the result here. I really doubt your tape was written correctly in the backup stage. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK are you sure that this tape was created using ADRDSSU. 01 //A255209$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B, 02 // REGION=0M,NOTIFY=SYSUID 03 //RESTORE EXEC PGM=ADRDSSU 04 //TAPE DD UNIT=680,DISP=SHR,LABEL=(1,SL), 05 //DSN=BACKUP.USRBKP,VOL=SER=USRBKP 06 //DASD DD UNIT=3390,VOL=SER=CT3T04,DISP=SHR 07 //SYSPRINT DD SYSOUT=* Jags, Check your tape management software and make sure this volume is the dataset you think it is. Also, is this tape not cataloged on your system that is on DD statement TAPE? Typically I only code //TAPE DD DISP=SHR,DSN=mytapename You might need to code UNIT=680 if the device is not in an esoteric name like TAPE. You might need to code VOLSER if the dataset is not cataloged. I rarely code volser or label when using a standard label cataloged tape. Next, in your control cards you have STORCLAS and MGMTCLAS. Is that needed? Are these classes on this system you are restoring to? If so, when the dataset is backed up and it had these classes to start with, you do not need to specify it again. The ACS code should drive it through and assign the correct classes. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
Hi Jagadishan. Did you really run the JCL with PARM='TYPRUN=NORUN'? If you did, the backup didn't actually run because the TYPRUN=NORUN parm specifies that the DUMP option will only be simulated! Stephen Mednick Computer Supervisory Services Sydney, Australia Asia/Pacific representatives for Innovation Data Processing, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Wednesday, 22 June 2011 8:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Restore Error - Adrdssu Hi, The back up went fine with CC=0. Below is my JCL //BACKUP$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=T, // REGION=5M,NOTIFY=SYSUID //DUMPDS EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //DASD1 DD VOL=SER=LDSN16,UNIT=3390,DISP=SHR //DASD2 DD VOL=SER=LDSN15,UNIT=3390,DISP=SHR //DASD3 DD VOL=SER=LDSN14,UNIT=3390,DISP=SHR //DASD4 DD VOL=SER=PUBLB3,UNIT=3390,DISP=SHR //DASD5 DD VOL=SER=PUBLB4,UNIT=3390,DISP=SHR //DASD6 DD VOL=SER=LDSN18,UNIT=3390,DISP=SHR //DASD7 DD VOL=SER=LPRJ20,UNIT=3390,DISP=SHR //DASD8 DD VOL=SER=LPRJ15,UNIT=3390,DISP=SHR //DASD9 DD VOL=SER=LPRJ16,UNIT=3390,DISP=SHR //DASD10 DD VOL=SER=LPRJ14,UNIT=3390,DISP=SHR //DASD11 DD VOL=SER=LIB001,UNIT=3390,DISP=SHR //DASD12 DD VOL=SER=LPRJ19,UNIT=3390,DISP=SHR //DASD13 DD VOL=SER=FREE01,UNIT=3390,DISP=SHR //DASD14 DD VOL=SER=FREE02,UNIT=3390,DISP=SHR //DASD15 DD VOL=SER=LPRJ18,UNIT=3390,DISP=SHR //DASD16 DD VOL=SER=LPRJ10,UNIT=3390,DISP=SHR //DASD17 DD VOL=SER=LPRJ17,UNIT=3390,DISP=SHR //TAPE1DD DSN=BACKUP.USRBKP,DISP=(NEW,CATLG), // UNIT=680,LABEL=(1,SL),VOL=SER=USRBKP //SYSIN DD * DUMP LIDD(DASD1 DASD2 DASD3 DASD4 DASD5 DASD6 DASD7 DASD8 DASD9 - DASD10 DASD11 DASD12 DASD13 DASD14 DASD15 DASD16 DASD17)- OUTDDNAME(TAPE1) - DS(INCL(XXA47467.** - U195530.** - U251034.** - U251050.** )) /* SYSPRINT : PAGE 0001 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 DUMP LIDD(DASD1 DASD2 DASD3 DASD4 DASD5 DASD6 DASD7 DASD8 DASD9 - DASD10 DASD11 DASD12 DASD13 DASD14 DASD15 DASD16 DASD17)- OUTDDNAME(TAPE1) - DS(INCL(XXA47467.** - U195530.** - U251034.** - U251050.** )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' ADR109I (R/I)-RI01 (01), 2011.172 18:54:06 INITIAL SCAN OF USER CONTROL STATEMEN ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2011.172 18:54:06 EXECUTION BEGINS ADR788I (001)-DIVSM(03), PROCESSING COMPLETED FOR CLUSTER U195530.IN.KSDS, 3 REC ADR801I (001)-DTDSC(01), DATA SET FILTERING IS COMPLETE. 182 OF 182 DATA SETS WE FOR OTHER REASONS. ADR454I (001)-DTDSC(01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED U195530.SPFLOG1.LIST U251050.SQL.OUTPUT U251034.PUNCH.DEPLUTI2 U251050.DSNUQUI.CNTL U195530.TRAIL.PS U195530.XEROX.PS U195530.XEROX13.PS U251034.PUNCH.DEPLUTI3 U251034.SQL.UTILITY U195530.PROCLIB U195530.JCLLIB U195530.CONTROL U195530.SAM.PS U195530.NEW.PS U251050.LOAD.EUTIL U195530.SPF1.LIST U195530.IN.PS U251034.UNLOAD.DEPLUTI PAGE 0002 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 U251050.UNLOAD.DEPTUTI U251050.UNLOAD.EMPLUTI U195530.SPFTEMP0.CNTL CLUSTER NAME U195530.IN.KSDS 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 CATALOG NAME CATALOG.CTSUSER.VZ16CAT COMPONENT NAME U195530.IN.KSDS.DATA COMPONENT NAME U195530.IN.KSDS.INDEX CLUSTER NAME U195530.MVS.RRDS CATALOG NAME CATALOG.CTSUSER.VZ16CAT COMPONENT NAME U195530.MVS.RRDS.DATA ADR006I (001)-STEND(02), 2011.172 18:57:08 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2011.172 18:57:08 TASK COMPLETED WITH RETURN CODE ADR012I (SCH)-DSSU (01), 2011.172 18:57:08 DFSMSDSS PROCESSING COMPLETE. HIGHEST Regards, Jags On Wed, Jun 22, 2011 at 4:12 PM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: jagadishan perumal wrote: 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK Do a TAPEMAP on that volume and post the result here. I really doubt your tape was written correctly in the backup stage. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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
Re: Restore Error - Adrdssu
On Wed, Jun 22, 2011 at 12:28 PM, Stephen Mednick ibmm...@css.au.comwrote: Hi Jagadishan. Did you really run the JCL with PARM='TYPRUN=NORUN'? If you did, the backup didn't actually run because the TYPRUN=NORUN parm specifies that the DUMP option will only be simulated! Stephen Mednick Computer Supervisory Services Sydney, Australia I don't think so, the PARM paremeter has a space preceding it which means it is ignored. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
Stephen Mednick wrote: Did you really run the JCL with PARM='TYPRUN=NORUN'? Hopefully not, because there is no comma to the left of PARM and we should see ADR031I if it was really mentioned. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
Yes you're right, I missed seeing it. Getting late here and the eyes are droopy! Stephen Mednick Computer Supervisory Services Sydney, Australia Asia/Pacific representatives for Innovation Data Processing, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Elardus Engelbrecht Sent: Wednesday, 22 June 2011 9:35 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Restore Error - Adrdssu Stephen Mednick wrote: Did you really run the JCL with PARM='TYPRUN=NORUN'? Hopefully not, because there is no comma to the left of PARM and we should see ADR031I if it was really mentioned. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
Stephen Mednick wrote: Yes you're right, I missed seeing it. Nevermind. It is all right! Getting late here and the eyes are droopy! Get a cup of good strong coffee for your eye! :-D :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
It must be some kind of mistakes , if you look further down yo see: ADR454I (001)-DTDSC(01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED mace -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
If this is the complete output then it never found any XXA47467.** datasets that were successfully processed to backup. Dennis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Wednesday, June 22, 2011 5:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Restore Error - Adrdssu Hi, The back up went fine with CC=0. Below is my JCL //BACKUP$ JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=T, // REGION=5M,NOTIFY=SYSUID //DUMPDS EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //DASD1 DD VOL=SER=LDSN16,UNIT=3390,DISP=SHR //DASD2 DD VOL=SER=LDSN15,UNIT=3390,DISP=SHR //DASD3 DD VOL=SER=LDSN14,UNIT=3390,DISP=SHR //DASD4 DD VOL=SER=PUBLB3,UNIT=3390,DISP=SHR //DASD5 DD VOL=SER=PUBLB4,UNIT=3390,DISP=SHR //DASD6 DD VOL=SER=LDSN18,UNIT=3390,DISP=SHR //DASD7 DD VOL=SER=LPRJ20,UNIT=3390,DISP=SHR //DASD8 DD VOL=SER=LPRJ15,UNIT=3390,DISP=SHR //DASD9 DD VOL=SER=LPRJ16,UNIT=3390,DISP=SHR //DASD10 DD VOL=SER=LPRJ14,UNIT=3390,DISP=SHR //DASD11 DD VOL=SER=LIB001,UNIT=3390,DISP=SHR //DASD12 DD VOL=SER=LPRJ19,UNIT=3390,DISP=SHR //DASD13 DD VOL=SER=FREE01,UNIT=3390,DISP=SHR //DASD14 DD VOL=SER=FREE02,UNIT=3390,DISP=SHR //DASD15 DD VOL=SER=LPRJ18,UNIT=3390,DISP=SHR //DASD16 DD VOL=SER=LPRJ10,UNIT=3390,DISP=SHR //DASD17 DD VOL=SER=LPRJ17,UNIT=3390,DISP=SHR //TAPE1DD DSN=BACKUP.USRBKP,DISP=(NEW,CATLG), // UNIT=680,LABEL=(1,SL),VOL=SER=USRBKP //SYSIN DD * DUMP LIDD(DASD1 DASD2 DASD3 DASD4 DASD5 DASD6 DASD7 DASD8 DASD9 - DASD10 DASD11 DASD12 DASD13 DASD14 DASD15 DASD16 DASD17)- OUTDDNAME(TAPE1) - DS(INCL(XXA47467.** - U195530.** - U251034.** - U251050.** )) /* SYSPRINT : PAGE 0001 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 DUMP LIDD(DASD1 DASD2 DASD3 DASD4 DASD5 DASD6 DASD7 DASD8 DASD9 - DASD10 DASD11 DASD12 DASD13 DASD14 DASD15 DASD16 DASD17)- OUTDDNAME(TAPE1) - DS(INCL(XXA47467.** - U195530.** - U251034.** - U251050.** )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' ADR109I (R/I)-RI01 (01), 2011.172 18:54:06 INITIAL SCAN OF USER CONTROL STATEMEN ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2011.172 18:54:06 EXECUTION BEGINS ADR788I (001)-DIVSM(03), PROCESSING COMPLETED FOR CLUSTER U195530.IN.KSDS, 3 REC ADR801I (001)-DTDSC(01), DATA SET FILTERING IS COMPLETE. 182 OF 182 DATA SETS WE FOR OTHER REASONS. ADR454I (001)-DTDSC(01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED U195530.SPFLOG1.LIST U251050.SQL.OUTPUT U251034.PUNCH.DEPLUTI2 U251050.DSNUQUI.CNTL U195530.TRAIL.PS U195530.XEROX.PS U195530.XEROX13.PS U251034.PUNCH.DEPLUTI3 U251034.SQL.UTILITY U195530.PROCLIB U195530.JCLLIB U195530.CONTROL U195530.SAM.PS U195530.NEW.PS U251050.LOAD.EUTIL U195530.SPF1.LIST U195530.IN.PS U251034.UNLOAD.DEPLUTI PAGE 0002 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 U251050.UNLOAD.DEPTUTI U251050.UNLOAD.EMPLUTI U195530.SPFTEMP0.CNTL CLUSTER NAME U195530.IN.KSDS 5695-DF175 DFSMSDSS V1R06.0 DATA SET SERVICES 2011.172 18:54 CATALOG NAME CATALOG.CTSUSER.VZ16CAT COMPONENT NAME U195530.IN.KSDS.DATA COMPONENT NAME U195530.IN.KSDS.INDEX CLUSTER NAME U195530.MVS.RRDS CATALOG NAME CATALOG.CTSUSER.VZ16CAT COMPONENT NAME U195530.MVS.RRDS.DATA ADR006I (001)-STEND(02), 2011.172 18:57:08 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2011.172 18:57:08 TASK COMPLETED WITH RETURN CODE ADR012I (SCH)-DSSU (01), 2011.172 18:57:08 DFSMSDSS PROCESSING COMPLETE. HIGHEST Regards, Jags On Wed, Jun 22, 2011 at 4:12 PM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: jagadishan perumal wrote: 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK Do a TAPEMAP on that volume and post the result here. I really doubt your tape was written correctly in the backup stage. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
In banlktikhgiqgw7zlhn4eedn5eyzu0u+...@mail.gmail.com, on 06/22/2011 at 03:02 PM, jagadishan perumal jagadish...@gmail.com said: Could'nt figure out the exact syntax error with my JCL. If there had been a syntax error then your job wouldn't have run. IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK should tell you what your problem is. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
Hi, The back up was taken at V1R6 and the restoration is happening at v1r12. Is there any version incompatibility. now i get U195530 1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 19:20 -ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN MO RESTORE INDD(TAPE1) OUTDD(DASD1 DASD2 DASD3 DASD4) - 0008000 DATASET(INCLUDE(U195530.** - 0009000 )) - 001 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 0011000 ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2011.173 19:20:31 INITIAL SCAN OF USER CONTROL STATEME ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 0ADR006I (001)-STEND(01), 2011.173 19:20:31 EXECUTION BEGINS 0ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL 1 RELEASE 6 MODIFICATION LEVEL 0 ON 2011.173 18:50:58 0ADR489I (001)-TDLOG(02), CLUSTER U195530.IN.KSDS WAS SELECTED CATALOG CATALOG.CTS3.USER.UCAT COMPONENT U195530.IN.KSDS.DATA COMPONENT U195530.IN.KSDS.INDEX 0ADR489I (001)-TDLOG(02), CLUSTER U195530.MVS.RRDS WAS SELECTED CATALOGCATALOG.CTS3.USER.UCAT COMPONENT U195530.MVS.RRDS.DATA 0ADR380E (001)-FRLBO(23), DATA SET U195530.SPFLOG1.LIST NOT PROCESSED, 18 0ADR489I (001)-TDLOG(01), DATA SET U195530.TRAIL.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX13.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.PROCLIB WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.JCLLIB WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.CONTROL WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAM.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.NEW.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SPF1.LIST WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.IN.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SPFTEMP0.CNTL WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAMEEHA1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAM2.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.I2.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.I1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.COBOL.PDS WAS SELECTED 1PAGE 0002 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 -ADR489I (001)-TDLOG(01), DATA SET U195530.LOADLIB.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.COND.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUTPUT.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX11.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.KARTHIK.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX14.PS WAS SELECTED 0ADR380E (001)-FRLBO(23), DATA SET U195530.ISPF.ISPPROF NOT PROCESSED, 18 0ADR489I (001)-TDLOG(01), DATA SET U195530.IF.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.JCL33.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.INPUT.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAMEEHA.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUTPUT.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX12.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.REPRO.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SORT.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAM1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OVERRIDE.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUT1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUT2.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUT3.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.TESTIN WAS SELECTED 0ADR040I (001)-TDLOG(01), PROCESSING BYPASSED DUE TO NORUN OPTION 0ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE L 0 U195530.SPFLOG1.LIST 0 U195530.ISPF.ISPPROF 0ADR454I (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED 0 U195530.TRAIL.PS 0 U195530.XEROX.PS 0 U195530.XEROX13.PS 1PAGE 0003 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 19:2 - U195530.PROCLIB 0 U195530.JCLLIB 0 U195530.CONTROL 0 U195530.SAM.PS 0 U195530.NEW.PS 0 U195530.SPF1.LIST 0 U195530.IN.PS 0 U195530.SPFTEMP0.CNTL 0 U195530.SAMEEHA1.PS 0 U195530.SAM2.PS 0 U195530.I2.PS 0 U195530.I1.PS 0 U195530.COBOL.PDS 0 U195530.LOADLIB.PDS 0
Re: Restore Error - Adrdssu
i have figured out the problem. Parm='type=norun' was just printing not restoring. . so took of this parameter and everything went fine. thanks all On 6/22/11, jagadishan perumal jagadish...@gmail.com wrote: Hi, The back up was taken at V1R6 and the restoration is happening at v1r12. Is there any version incompatibility. now i get U195530 1PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 19:20 -ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN MO RESTORE INDD(TAPE1) OUTDD(DASD1 DASD2 DASD3 DASD4) - 0008000 DATASET(INCLUDE(U195530.** - 0009000 )) - 001 CATALOG STORCLAS(STANDARD) MGMTCLAS(STANDARD) 0011000 ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2011.173 19:20:31 INITIAL SCAN OF USER CONTROL STATEME ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK 0ADR006I (001)-STEND(01), 2011.173 19:20:31 EXECUTION BEGINS 0ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL 1 RELEASE 6 MODIFICATION LEVEL 0 ON 2011.173 18:50:58 0ADR489I (001)-TDLOG(02), CLUSTER U195530.IN.KSDS WAS SELECTED CATALOG CATALOG.CTS3.USER.UCAT COMPONENT U195530.IN.KSDS.DATA COMPONENT U195530.IN.KSDS.INDEX 0ADR489I (001)-TDLOG(02), CLUSTER U195530.MVS.RRDS WAS SELECTED CATALOGCATALOG.CTS3.USER.UCAT COMPONENT U195530.MVS.RRDS.DATA 0ADR380E (001)-FRLBO(23), DATA SET U195530.SPFLOG1.LIST NOT PROCESSED, 18 0ADR489I (001)-TDLOG(01), DATA SET U195530.TRAIL.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX13.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.PROCLIB WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.JCLLIB WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.CONTROL WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAM.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.NEW.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SPF1.LIST WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.IN.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SPFTEMP0.CNTL WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAMEEHA1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAM2.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.I2.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.I1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.COBOL.PDS WAS SELECTED 1PAGE 0002 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 -ADR489I (001)-TDLOG(01), DATA SET U195530.LOADLIB.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.COND.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUTPUT.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX11.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.KARTHIK.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX14.PS WAS SELECTED 0ADR380E (001)-FRLBO(23), DATA SET U195530.ISPF.ISPPROF NOT PROCESSED, 18 0ADR489I (001)-TDLOG(01), DATA SET U195530.IF.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.JCL33.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.INPUT.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAMEEHA.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUTPUT.PDS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.XEROX12.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.REPRO.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SORT.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.SAM1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OVERRIDE.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUT1.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUT2.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.OUT3.PS WAS SELECTED 0ADR489I (001)-TDLOG(01), DATA SET U195530.TESTIN WAS SELECTED 0ADR040I (001)-TDLOG(01), PROCESSING BYPASSED DUE TO NORUN OPTION 0ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE L 0 U195530.SPFLOG1.LIST 0 U195530.ISPF.ISPPROF 0ADR454I (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED 0 U195530.TRAIL.PS 0 U195530.XEROX.PS 0 U195530.XEROX13.PS 1PAGE 0003 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.173 19:2 - U195530.PROCLIB 0 U195530.JCLLIB 0 U195530.CONTROL 0 U195530.SAM.PS 0 U195530.NEW.PS 0 U195530.SPF1.LIST 0 U195530.IN.PS 0
Re: Restore Error - Adrdssu
Jags, PARM='TYPRUN=NORUN' will show you how the restore could go. So it says it will restore all files but the following U195530.SPFLOG1.LIST 0 U195530.ISPF.ISPPROF 0 So I am not sure what your issue is now. You are using different datasets from the original question you posted. Before you used XX* now U19* Be consistent in your problem description. Are you using the same tape as before that got the S002? Are these datasets on that tape as well? No problem I know of, but you should search the IBM IBMLINK database to see if there are any issues. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Restore Error - Adrdssu
On Wed, Jun 22, 2011 at 3:30 PM, jagadishan perumal jagadish...@gmail.comwrote: i have figured out the problem. Parm='type=norun' was just printing not restoring. . so took of this parameter and everything went fine. thanks all Yes, but you had already made changes before that to make the restore work in NORUN mode. What did you change to get rid of the following message ??? 15.19.25 JOB02012 IEC036I 002-30,IGC0005E,RESTORE$,STEP1,TAPE1,0680,USRBKP,BACK Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 question on DFDSS/ADRDSSU
Could you eliminate the problem completely by directing the restore to a different volume instead of the default? Well, yes, of course, but that would require effort and aforethought on my part ... not bloody likely (grin) Chris Hoelscher IDMS DB2 Database Administrator 502-476-2538 You only need to test the programs you don't want to get called on later The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS 1.11 question on DFDSS/ADRDSSU
I occasionally restore using ADRDSSU and rename the restored dataset to my HLQ - so that I can have an older version of a dataset to compare to the current dataset. By default (it appears) - the restore process will put the restored/renamed dataset on the same DASD volume as from which it was originally backed up (which is fine with me ) However - at times I need this dataset to remain for days or even weeks - the job that does the weekly backup of this DASD VOLUME does not have authority to read/backup any datasets with my HLQ (nor should it) - thus the backup abends and I get yelled at Yes - I could remember to force the restored dataset to another DASD volume -but - my real question (and preferred solution ) is - is there an option to tell ADSDRRU if I do not have authority to backup any dataset - don't try ??( I did attempt to read z/OS V1R11.0 DFSMSdss Storage Administration) but did not find any help there - so either I cannot read IBM-ese or my hoped-for solution does not exist - thanks for any suggestions Chris Hoelscher IDMS DB2 Database Administrator 502-476-2538 You only need to test the programs you don't want to get called on later The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 question on DFDSS/ADRDSSU
add DS(INCLUDE(**) EXCLUDE(SYS1.VTOC.**, SYS1.VVDS.**, *OMVS.**, hlq.**)) or as you need. (we have a separate backup step for *OMVS*.** files). On Wed, May 18, 2011 at 12:02 PM, Chris Hoelscher choelsc...@humana.com wrote: I occasionally restore using ADRDSSU and rename the restored dataset to my HLQ - so that I can have an older version of a dataset to compare to the current dataset. By default (it appears) - the restore process will put the restored/renamed dataset on the same DASD volume as from which it was originally backed up (which is fine with me ) However - at times I need this dataset to remain for days or even weeks - the job that does the weekly backup of this DASD VOLUME does not have authority to read/backup any datasets with my HLQ (nor should it) - thus the backup abends and I get yelled at Yes - I could remember to force the restored dataset to another DASD volume -but - my real question (and preferred solution ) is - is there an option to tell ADSDRRU if I do not have authority to backup any dataset - don't try ??( I did attempt to read z/OS V1R11.0 DFSMSdss Storage Administration) but did not find any help there - so either I cannot read IBM-ese or my hoped-for solution does not exist - thanks for any suggestions Chris Hoelscher IDMS DB2 Database Administrator 502-476-2538 You only need to test the programs you don't want to get called on later The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 question on DFDSS/ADRDSSU
Chris, Are they full volume or dataset-level backups that you're restoring from? SMS or non-SMS volumes? Could you eliminate the problem completely by directing the restore to a different volume instead of the default? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Hoelscher Sent: Wednesday, May 18, 2011 12:02 PM To: IBM-MAIN@bama.ua.edu Subject: z/OS 1.11 question on DFDSS/ADRDSSU I occasionally restore using ADRDSSU and rename the restored dataset to my HLQ - so that I can have an older version of a dataset to compare to the current dataset. By default (it appears) - the restore process will put the restored/renamed dataset on the same DASD volume as from which it was originally backed up (which is fine with me ) However - at times I need this dataset to remain for days or even weeks - the job that does the weekly backup of this DASD VOLUME does not have authority to read/backup any datasets with my HLQ (nor should it) - thus the backup abends and I get yelled at Yes - I could remember to force the restored dataset to another DASD volume -but - my real question (and preferred solution ) is - is there an option to tell ADSDRRU if I do not have authority to backup any dataset - don't try ??( I did attempt to read z/OS V1R11.0 DFSMSdss Storage Administration) but did not find any help there - so either I cannot read IBM-ese or my hoped-for solution does not exist - thanks for any suggestions Chris Hoelscher IDMS DB2 Database Administrator 502-476-2538 You only need to test the programs you don't want to get called on later The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 question on DFDSS/ADRDSSU
If datasets with your HLQ need the protection you indicate, you should not be allowed to place them on the same volumes as datasets that don't. The fact that you can means you should take the extra care to see that you don't. It should not be that big a deal. You have already added one of the RENAME operands to your RESTORE statement. On the same line, simply add an OUTDYNAM operand pointing to a pack where your datasets can reside without interfering with normal operations. Alternately, since the restored dataset was not yours originally, it really doesn't need the protection afforded by your HLQ. Rename it to something other than your HLQ that can reside safely on the original volume. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Hoelscher Sent: Wednesday, May 18, 2011 10:02 AM To: IBM-MAIN@bama.ua.edu Subject: z/OS 1.11 question on DFDSS/ADRDSSU I occasionally restore using ADRDSSU and rename the restored dataset to my HLQ - so that I can have an older version of a dataset to compare to the current dataset. By default (it appears) - the restore process will put the restored/renamed dataset on the same DASD volume as from which it was originally backed up (which is fine with me ) However - at times I need this dataset to remain for days or even weeks - the job that does the weekly backup of this DASD VOLUME does not have authority to read/backup any datasets with my HLQ (nor should it) - thus the backup abends and I get yelled at Yes - I could remember to force the restored dataset to another DASD volume -but - my real question (and preferred solution ) is - is there an option to tell ADSDRRU if I do not have authority to backup any dataset - don't try ??( I did attempt to read z/OS V1R11.0 DFSMSdss Storage Administration) but did not find any help there - so either I cannot read IBM-ese or my hoped-for solution does not exist - thanks for any suggestions -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
Yes, some of the dataset were copied and the target dataset were not cataloged. In my earlier JCL, I have not specified Process(SYS1), but still I was able to copy SYS1 datasets. Regards Saurabh Khandelwal On 4/7/2011 7:24 AM, chen lucky wrote: I have following question about this ADRDSSU COPY, 1.in original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged? seems not the reason. 2.'PROCESS(SYS1)' is also not specified, but some SYS1.** get copied successfully, still do not know why, strange…… 2011/4/7 Schwarz, Barry Abarry.a.schw...@boeing.com I had non-managed VSAM datasets (zFS to be exact) on z/OS 1.8. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, April 06, 2011 5:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue I see you are at z/OS V1.9. VSAM datasets If I remember are always SMS Managed and it is not until z/OS V1.12 that you can use indirect VSAM cataloging. I am not sure you can copy the same name VSAM dataset. You may need to copy to a new VSAM dataset name -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
VSAM data sets are required to be cataloged. If you look up the ADR468E message is says: If the REPLACE or REPLACEUNCONDITIONAL keyword was not specified, one of the following conditions applies: * If DELETE is specified and the entry name is a SYS1., page, or swap data set, the RENAMEUNCONDITIONAL or PROCESS(SYS1) subparameter was not specified. * If the entry name is a cluster name and DELETE was not specified: (1) the RENAMEUNCONDITIONAL subparameter was not specified or (2) the RECAT subparameter was not specified. * If the entry name is an alternate index or a user catalog name: (1) the DELETE subparameter was not specified or (2) the RENAMEUNCONDITIONAL subparameter was specified. * If the entry name is a user catalog name, INDDNAME or INDYNAM was specified. So you either need to specify the DELETE keyword if you are trying to move the data sets. If you are not trying to move the data sets and just want another copy then you need to specify the RECAT(catalogname) where the catalog catalogname is not in the standard order of search (no alias defined to the master catalog). Or if you are trying to just have a copy with a new name then you need to specify the RENAMEU(high_level_qualifier) to rename the data set's high level qualifier to which will then catalog the target VSAM data sets with the new name (other renaming options are available, look up the RENAMEU keyword in the DSS Storage Admin Guide). Some of your non-VSAM data sets may have been copied because they do not have the requirement to be cataloged. So then there is no conflict because they can be copied and leave the target data set uncataloged. BYPASSACS(**) and NSC will bypass the ACS routines and allow you to direct the datasets to a non-SMS volume. Keep in mind though that some data set types require SMS management. Hope that helps. Justin Eastman IBM DFSMSdss Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
The error with the IODF (ADR468E) looks like it was caused by the lack of PROCESS(SYS1) parameter. On the other hand, the parameter for copying VSAM properly is SPHERE. I copied your last try and it worked ok for me. Maybe the last //* is not at the column 1?. I would delete it and try again I usually copy VSAM and nonVSAM at the same time with SPHERE with no problem. On Wed, Apr 6, 2011 at 7:47 AM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: No, I am not using any parameter for coping VSAM dataset. I was asking you to suggest me , if you have idea about any parameter, which can be useful for coping VSAM dataset. Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
I am using below JCL and this also not able to backup VSAM dataset. I am getting same error. JCL //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=DMTCAT,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYSUCAT.** - OMVS.**- MVSSMP*.** - )) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - OUTDDNAME(OUTVOL1) - PERCENTUTILIZED(100) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR O/P 0ADR455W (001)-DDDS (01), THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSE 0 CENTER.HFS 0 DFHSM.BCDS 0 DFHSM.MCDS 0 DFHSM.OCDS 0 IPCS.DATASET.DIRECTRY 0 IPCS.PROBLEM.DIRECTRY 0 PAGE.TESTMVS.COMMON 0 PAGE.TESTMVS.LOCAL 0 PAGE.TESTMVS.PLPA 1PAGE 0009 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.096 07:50 - SYS1.ENULANG Regards Saurabh On 4/6/2011 1:36 PM, Gonzalo Cengotita wrote: The error with the IODF (ADR468E) looks like it was caused by the lack of PROCESS(SYS1) parameter. On the other hand, the parameter for copying VSAM properly is SPHERE. I copied your last try and it worked ok for me. Maybe the last //* is not at the column 1?. I would delete it and try again I usually copy VSAM and nonVSAM at the same time with SPHERE with no problem. On Wed, Apr 6, 2011 at 7:47 AM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: No, I am not using any parameter for coping VSAM dataset. I was asking you to suggest me , if you have idea about any parameter, which can be useful for coping VSAM dataset. Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
Hi, Can you check if the target volume has enough space ?? On Wed, Apr 6, 2011 at 1:55 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: I am using below JCL and this also not able to backup VSAM dataset. I am getting same error. JCL //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=DMTCAT,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYSUCAT.** - OMVS.**- MVSSMP*.** - )) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - OUTDDNAME(OUTVOL1) - PERCENTUTILIZED(100) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR O/P 0ADR455W (001)-DDDS (01), THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSE 0 CENTER.HFS 0 DFHSM.BCDS 0 DFHSM.MCDS 0 DFHSM.OCDS 0 IPCS.DATASET.DIRECTRY 0 IPCS.PROBLEM.DIRECTRY 0 PAGE.TESTMVS.COMMON 0 PAGE.TESTMVS.LOCAL 0 PAGE.TESTMVS.PLPA 1PAGE 0009 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.096 07:50 - SYS1.ENULANG Regards Saurabh On 4/6/2011 1:36 PM, Gonzalo Cengotita wrote: The error with the IODF (ADR468E) looks like it was caused by the lack of PROCESS(SYS1) parameter. On the other hand, the parameter for copying VSAM properly is SPHERE. I copied your last try and it worked ok for me. Maybe the last //* is not at the column 1?. I would delete it and try again I usually copy VSAM and nonVSAM at the same time with SPHERE with no problem. On Wed, Apr 6, 2011 at 7:47 AM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: No, I am not using any parameter for coping VSAM dataset. I was asking you to suggest me , if you have idea about any parameter, which can be useful for coping VSAM dataset. Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
I have enough space available in target volume. Also if it is space issue, I should have got abend code 37 . Also, I tried coping other volume as well, where I had VASAM dataset and got same error. Regards Saurabh Khandelwal On 4/6/2011 2:26 PM, jagadishan perumal wrote: Hi, Can you check if the target volume has enough space ?? On Wed, Apr 6, 2011 at 1:55 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com mailto:saurabh.khandel...@oracle.com wrote: I am using below JCL and this also not able to backup VSAM dataset. I am getting same error. JCL //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=DMTCAT,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYSUCAT.** - OMVS.**- MVSSMP*.** - )) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - OUTDDNAME(OUTVOL1) - PERCENTUTILIZED(100) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR O/P 0ADR455W (001)-DDDS (01), THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSE 0 CENTER.HFS 0 DFHSM.BCDS 0 DFHSM.MCDS 0 DFHSM.OCDS 0 IPCS.DATASET.DIRECTRY 0 IPCS.PROBLEM.DIRECTRY 0 PAGE.TESTMVS.COMMON 0 PAGE.TESTMVS.LOCAL 0 PAGE.TESTMVS.PLPA 1PAGE 0009 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.096 07:50 - SYS1.ENULANG Regards Saurabh On 4/6/2011 1:36 PM, Gonzalo Cengotita wrote: The error with the IODF (ADR468E) looks like it was caused by the lack of PROCESS(SYS1) parameter. On the other hand, the parameter for copying VSAM properly is SPHERE. I copied your last try and it worked ok for me. Maybe the last //* is not at the column 1?. I would delete it and try again I usually copy VSAM and nonVSAM at the same time with SPHERE with no problem. On Wed, Apr 6, 2011 at 7:47 AM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com mailto:saurabh.khandel...@oracle.com wrote: No, I am not using any parameter for coping VSAM dataset. I was asking you to suggest me , if you have idea about any parameter, which can be useful for coping VSAM dataset. Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu mailto:lists...@bama.ua.edu 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 lists...@bama.ua.edu mailto:lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh I have been following this thread. I see you are at z/OS V1.9. VSAM datasets If I remember are always SMS Managed and it is not until z/OS V1.12 that you can use indirect VSAM cataloging. I am not sure you can copy the same name VSAM dataset. You may need to copy to a new VSAM dataset name So, has this process you are using worked in the past and suddenly stopped working? When was the last successfully run? What version of z/OS was it under? Is the name you are copying already cataloged? If so, I am not sure you can use DFDSS to do this. You may need a second step to copy your IODF (or other ) VSAM datasets separately. I have had situations in the past where I had to copy everything but the VSAM files with DFDSS and then used another process to copy the VSAM files. Do you still have the last successful run output? Can you compare the listings (current and old one) and see what is different or the same? Are you creating a new system volume? You do not want to use DELETE, it may accidently delete your live datasets Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
VSAM datasets If I remember are always SMS Managed and. NO. I have several z/OS datasets on my SYSRES volume sets that are not SMS managed. ...z/OS V1.12 that you can use indirect VSAM cataloging. I am not sure. I will have to go look this up. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
I am using below JCL and this also not able to backup VSAM dataset. I am getting same error. JCL //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=4M ,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=DMTCAT,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYSUCAT.** - OMVS.**- MVSSMP*.** - )) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - OUTDDNAME(OUTVOL1) - PERCENTUTILIZED(100) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR The ADR468E has the following entry in the message If the REPLACE or REPLACEUNCONDITIONAL keyword was specified, either the data set does not qualify for preallocation or a preallocated target does not exist, and one of the following conditions applies: If DELETE is specified and the entry name is a SYS1., page, or swap data set, the RENAMEUNCONDITIONAL or PROCESS(SYS1) subparameter was not specified. If the entry name is a cluster name and DELETE was not specified: (1) the RENAMEUNCONDITIONAL subparameter was not specified, or (2) the RECAT subparameter was not specified. If the entry name is an alternate index or a user catalog name: (1) the DELETE subparameter was not specified, or (2) the RENAMEUNCONDITIONAL subparameter was specified. I would not use REPLACE because the VSAM dataset probably does not exist before the COPY function. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
SYS1 datasets needs the additional parameter of PROCESS(SYS1) that I didn't see in your JCL example. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Mike Wickman Technical Services Phone 913-236-1663 Cell 913-449-6423 Fax 913-236-1555 email mwick...@waddell.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, April 05, 2011 8:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] ADRDSSU issue Hi, 1) Instead of copying your IODF cluster. You can even use your existing IODF and Just IPL from the address of the new COD sysres volume, but point LOADPARM at your normal IODF volume. 2) Or else you can define a new Cluster at the target volume and copy the existing IODF cluster from the source using the load module CBDMGHCP. You can google it to find the sample JCL for CBDMGHCP. Regards, Jags On Tue, Apr 5, 2011 at 8:48 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* * SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen lucky chenluck...@gmail.com chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWAL saurabh.khandel...@oracle.com saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com http://www.healthmarkets.com/http://www.healthmarkets.com/ http://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products
Re: ADRDSSU issue
Hello, I am using below JCL now and getting below error. But now I am not getting error for VSAM dataset. O/P *0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG1 IN CATALOG CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE. 0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG2 IN CATALOG CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE. * *0ADR410E error description is : *Copy with DELETE specified requires exclusive access to the data set to be deleted. When you are to rename the data set being copied, either source or target data set being used will cause copy to fail and the system to issue this message. The data set identified in the message represents either the source or target data set that is in use. JCL : //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP1EXEC PGM=ADRDSSU,REGION=2M,PARM='' //D1 DD UNIT=3390,VOL=SER=DMTCAT,DISP=SHR //D2 DD UNIT=3390,VOL=SER=RES001,DISP=SHR //DUMMY DD DUMMY //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY DS(INCLUDE( - CEE.** - DFS.** - GIM.**- ISF.**- ISP.** - SYS1.** - PASSWORD.** - TCPIP.** )- EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - )) - INDD(D1 ) - OUTDD(D2) - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - PROCESS(SYS1) - TOL(ENQF) ALLDATA(*) CAT SPHERE DELETE PURGE /* Regards Saurabh Khandelwal On 4/6/2011 6:54 PM, Michael Wickman wrote: SYS1 datasets needs the additional parameter of PROCESS(SYS1) that I didn't see in your JCL example. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Mike Wickman Technical Services Phone 913-236-1663 Cell 913-449-6423 Fax 913-236-1555 email mwick...@waddell.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, April 05, 2011 8:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] ADRDSSU issue Hi, 1) Instead of copying your IODF cluster. You can even use your existing IODF and Just IPL from the address of the new COD sysres volume, but point LOADPARM at your normal IODF volume. 2) Or else you can define a new Cluster at the target volume and copy the existing IODF cluster from the source using the load module CBDMGHCP. You can google it to find the sample JCL for CBDMGHCP. Regards, Jags On Tue, Apr 5, 2011 at 8:48 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* * SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen luckychenluck...@gmail.com chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWALsaurabh.khandel...@oracle.com saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am
Re: ADRDSSU issue
*0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG1 IN CATALOG CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE. 0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG2 IN CATALOG CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE. * *0ADR410E error description is : *Copy with DELETE specified requires exclusive access to the data set to be deleted. When you are to rename the data set being copied, either source or target data set being used will cause copy to fail and the system to issue this message. The data set identified in the message represents either the source or target data set that is in use. You are trying to delete your live datasets on DMTCAT. Did you want to delete your datasets on DMTCAT? If you code DELETE it will delete the Datasets you are copying. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
This error means the dataset is opened by an application and you can't delete it, it has nothing to do with being VSAM or sequential On Wed, Apr 6, 2011 at 4:24 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello, I am using below JCL now and getting below error. But now I am not getting error for VSAM dataset. O/P *0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG1 IN CATALOG CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE. 0ADR410E (001)-DDFLT(02), DATA SET SYS1.NFS.LOG2 IN CATALOG CATALOG.MASTER.MCAT ON VOLUME DMTCAT FAILED SERIALIZATION FOR DELETE. * *0ADR410E error description is : *Copy with DELETE specified requires exclusive access to the data set to be deleted. When you are to rename the data set being copied, either source or target data set being used will cause copy to fail and the system to issue this message. The data set identified in the message represents either the source or target data set that is in use. JCL : //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP1EXEC PGM=ADRDSSU,REGION=2M,PARM='' //D1 DD UNIT=3390,VOL=SER=DMTCAT,DISP=SHR //D2 DD UNIT=3390,VOL=SER=RES001,DISP=SHR //DUMMY DD DUMMY //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY DS(INCLUDE( - CEE.** - DFS.** - GIM.**- ISF.**- ISP.** - SYS1.** - PASSWORD.** - TCPIP.** )- EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - )) - INDD(D1 ) - OUTDD(D2) - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - PROCESS(SYS1) - TOL(ENQF) ALLDATA(*) CAT SPHERE DELETE PURGE /* Regards Saurabh Khandelwal On 4/6/2011 6:54 PM, Michael Wickman wrote: SYS1 datasets needs the additional parameter of PROCESS(SYS1) that I didn't see in your JCL example. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Mike Wickman Technical Services Phone 913-236-1663 Cell 913-449-6423 Fax 913-236-1555 email mwick...@waddell.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, April 05, 2011 8:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] ADRDSSU issue Hi, 1) Instead of copying your IODF cluster. You can even use your existing IODF and Just IPL from the address of the new COD sysres volume, but point LOADPARM at your normal IODF volume. 2) Or else you can define a new Cluster at the target volume and copy the existing IODF cluster from the source using the load module CBDMGHCP. You can google it to find the sample JCL for CBDMGHCP. Regards, Jags On Tue, Apr 5, 2011 at 8:48 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* * SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen luckychenluck...@gmail.com chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had
Re: ADRDSSU issue
I had non-managed VSAM datasets (zFS to be exact) on z/OS 1.8. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, April 06, 2011 5:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue I see you are at z/OS V1.9. VSAM datasets If I remember are always SMS Managed and it is not until z/OS V1.12 that you can use indirect VSAM cataloging. I am not sure you can copy the same name VSAM dataset. You may need to copy to a new VSAM dataset name -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
I have following question about this ADRDSSU COPY, 1.in original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged? seems not the reason. 2.'PROCESS(SYS1)' is also not specified, but some SYS1.** get copied successfully, still do not know why, strange…… 2011/4/7 Schwarz, Barry A barry.a.schw...@boeing.com I had non-managed VSAM datasets (zFS to be exact) on z/OS 1.8. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, April 06, 2011 5:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue I see you are at z/OS V1.9. VSAM datasets If I remember are always SMS Managed and it is not until z/OS V1.12 that you can use indirect VSAM cataloging. I am not sure you can copy the same name VSAM dataset. You may need to copy to a new VSAM dataset name -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ADRDSSU issue
Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
Hi, You can use the below as sample JCL : * //CPxxx EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA //TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA //SYSIN DD * COPY LOGINDD(FROM1) OUTDD(TO1) TOL(IOERROR) - ALLDATA(*) ALLEXCP ADMIN PURGE - DELETE RECAT(*) ALLMULTI WAIT(0,0) - DS(INCL(**),EXCL(SYS1.VTOCIX.*,SYS1.VVDS.*)) PROCESS(UNDEF) * BYPASSACS(**) NULLSTORCLAS You can add the last line inturn it will bypass SMS rules but generally it is not recommended. Regards, Jags On Tue, Apr 5, 2011 at 7:38 PM, Richard Marchant richard.march...@shoden.co.za wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
Re: ADRDSSU issue
Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm
Re: ADRDSSU issue
Thanks Jagdishan, But still I am not able to copy my VSAM dataset, which is also available in that volume. Rest all dataset are copied successfully. Can you please tell me the way to copy VSAM dataset as well in the same JCL. Regards Saurabh Khandelwal On 4/5/2011 7:54 PM, jagadishan perumal wrote: Hi, You can use the below as sample JCL : * //CPxxx EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA //TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA //SYSIN DD * COPY LOGINDD(FROM1) OUTDD(TO1) TOL(IOERROR) - ALLDATA(*) ALLEXCP ADMIN PURGE - DELETE RECAT(*) ALLMULTI WAIT(0,0) - DS(INCL(**),EXCL(SYS1.VTOCIX.*,SYS1.VVDS.*)) PROCESS(UNDEF) * BYPASSACS(**) NULLSTORCLAS You can add the last line inturn it will bypass SMS rules but generally it is not recommended. Regards, Jags On Tue, Apr 5, 2011 at 7:38 PM, Richard Marchant richard.march...@shoden.co.za wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh
Re: ADRDSSU issue
Hi, Please share us the Error message copying the VSAM Datasets. I mean can you point out the ADRxxx message related to the VSAM copy failure. On Tue, Apr 5, 2011 at 8:16 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Thanks Jagdishan, But still I am not able to copy my VSAM dataset, which is also available in that volume. Rest all dataset are copied successfully. Can you please tell me the way to copy VSAM dataset as well in the same JCL. Regards Saurabh Khandelwal On 4/5/2011 7:54 PM, jagadishan perumal wrote: Hi, You can use the below as sample JCL : * //CPxxx EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //FROM1 DD VOL=SER=xxx,DISP=SHR,UNIT=SYSALLDA //TO1 DD VOL=SER=yyy,DISP=SHR,UNIT=SYSALLDA //SYSIN DD * COPY LOGINDD(FROM1) OUTDD(TO1) TOL(IOERROR) - ALLDATA(*) ALLEXCP ADMIN PURGE - DELETE RECAT(*) ALLMULTI WAIT(0,0) - DS(INCL(**),EXCL(SYS1.VTOCIX.*,SYS1.VVDS.*)) PROCESS(UNDEF) * BYPASSACS(**) NULLSTORCLAS You can add the last line inturn it will bypass SMS rules but generally it is not recommended. Regards, Jags On Tue, Apr 5, 2011 at 7:38 PM, Richard Marchant richard.march...@shoden.co.za wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.comhttp://www.healthmarkets.com/ http://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S
Re: ADRDSSU issue
In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWAL saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed. Can anybody help me to resolve this issue. Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message
Re: ADRDSSU issue
Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen lucky chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWAL saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEESAMP BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTASN1 ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBPXMENU ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEELKED BE ADR396I (001)-NEWDS(01), DATA SET SYS1.SISTCMIP ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DBBLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.MIGLIB ALLOCATED, ON VOLUME(S): RES001 ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET ISF.SISFJCL BEC *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET CEE.SCEEH.SYS.H* ADR396I (001)-NEWDS(01), DATA SET SYS1.MSGENU ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.DGTTLIB ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SAPPMOD1 ALLOCATED, ON VOLUME(S): RES001 ADR744W (001)-MRPAM(01), NO VALID MEMBERS WERE FOUND FOR PDS DATA SET SYS1.SAPPM ADR396I (001)-NEWDS(01), DATA SET SYS1.HRFCLST ALLOCATED, ON VOLUME(S): RES001 ADR396I (001)-NEWDS(01), DATA SET SYS1.SBLSKEL0 ALLOCATED, ON VOLUME(S): RES001 As per my knowledge, only non SMS managed dataset used to be on RES volume. Then I am not sure, why I am getting above error. Also the RES volume is non SMS managed
Re: ADRDSSU issue
Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* *SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen luckychenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWALsaurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA(*) CANCELERROR. But, I am getting below error while doing copy for some of the dataset. *ADR713E (001)-ALLOC(01), UNABLE TO ALLOCATE SMS MANAGED DATA SET TCPIP.SEZAXAWL* ADR713E (001)-ALLOC
Re: ADRDSSU issue
Hi, 1) Instead of copying your IODF cluster. You can even use your existing IODF and Just IPL from the address of the new COD sysres volume, but point LOADPARM at your normal IODF volume. 2) Or else you can define a new Cluster at the target volume and copy the existing IODF cluster from the source using the load module CBDMGHCP. You can google it to find the sample JCL for CBDMGHCP. Regards, Jags On Tue, Apr 5, 2011 at 8:48 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* * SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen lucky chenluck...@gmail.com chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWAL saurabh.khandel...@oracle.com saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com http://www.healthmarkets.com/http://www.healthmarkets.com/ http://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume
Re: ADRDSSU issue
add PROCESS(SYS1), then have a try. 2011/4/5 SAURABH KHANDELWAL saurabh.khandel...@oracle.com Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* *SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen luckychenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWALsaurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com http://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD SYSOUT=* //RES1IN DD UNIT=3390,VOL=SER=DMTRES,DISP=SHR //RES1OUT DD UNIT=3390,VOL=SER=RES001,DISP=SHR //SYSIN DD * COPY INDD(RES1IN) OUTDD(RES1OUT) - DS(EXCLUDE(SYS1.VTOCIX.* - SYS1.VVDS.* - )) - TOLERATE(ENQF) SHARE ALLEXCP ALLDATA
Re: ADRDSSU issue
oh, sorry, 'PROCESS(SYS1)' is a control stmt that can be specified AS input to ADRDSSU(DDname SYSIN), NOT a parameter, ;-) Do not know whether it work or not, cause from your job's output, I got some SYS1.** get copied successfully, Just have a try. 2011/4/6 chen lucky chenluck...@gmail.com add PROCESS(SYS1), then have a try. 2011/4/5 SAURABH KHANDELWAL saurabh.khandel...@oracle.com Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* *SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen luckychenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWALsaurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com http://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of SAURABH KHANDELWAL Sent: Tuesday, April 05, 2011 7:58 AM To: IBM-MAIN@bama.ua.edu Subject: ADRDSSU issue Hello, I am trying to copy my SYSRES volume( ex: IPE100) into one new volume ( ex IPE101). All the dataset inside IPE100 is managed by indirect cataloging. I am using below JCL for this function. //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=0M,COND=(0,LT) //SYSPRINT DD
Re: ADRDSSU issue
use this and let me know what you get.. //VFRVOLSER EXEC PGM=ADRDSSU,PARM='LINECNT=',REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=FRVOLSER,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=TOVOLSER,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYS1.DUMP.** - SYS1.MAN%.** - SYSMCAT.** - SYSUCAT.** - OMVS.**- PAGE.** - MVSSMP*.** ) - BY((DSORG NE VSAM), - (DSORG NE HFS ), - (DSORG NE ZFS ))) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - OUTDDNAME( - OUTVOL1 - ) - PERCENTUTILIZED( - 100 - ) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR //* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
aah,forgot remove by condition so job can be .. //VFRVOLSER EXEC PGM=ADRDSSU,REGION=4M,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=FRVOLSER,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=TOVOLSER,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYSUCAT.** - OMVS.**- MVSSMP*.** - )) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - OUTDDNAME(OUTVOL1) - PERCENTUTILIZED(100) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR //* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
Ok, I will run this in 15 min . and send you output On 4/6/2011 9:40 AM, Ravi Gaur wrote: aah,forgot remove by condition so job can be .. //VFRVOLSER EXEC PGM=ADRDSSU,REGION=4M,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=FRVOLSER,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=TOVOLSER,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYSUCAT.** - OMVS.**- MVSSMP*.** - )) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - OUTDDNAME(OUTVOL1) - PERCENTUTILIZED(100) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR //* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU issue
Output of below JCL *JCL Used* //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID //STEP2 EXEC PGM=ADRDSSU,REGION=4M,PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //INVOL1DD VOL=SER=DMTRES,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR //SYSIN DD * COPY DATASET(INCLUDE(**) - EXCLUDE(SYS1.VTOCIX.** - SYS1.VVDS.** - SYSUCAT.** - OMVS.**- MVSSMP*.** - )) - LOGINDDNAME(INVOL1) - ALLDATA(*) - ALLEXCP - CANCELERROR - BYPASSACS(**) - FORCE - NULLMGMTCLAS - NULLSTORCLAS - OUTDDNAME(OUTVOL1) - PERCENTUTILIZED(100) - PROCESS(SYS1) - REPLACE - SHARE - SPHERE - TGTALLOC(SOURCE) - TOLERATE(ENQFAILURE) - ADMINISTRATOR //* *O/P* * TOP OF DATA ** 1 J E S 2 J O B L O G -- S Y S T E M M V S T -- N O D E 0 04.07.35 JOB05545 WEDNESDAY, 06 APR 2011 04.07.35 JOB05545 IRR010I USERID SYSPRG1 IS ASSIGNED TO THIS JOB. 04.07.35 JOB05545 ICH70001I SYSPRG1 LAST ACCESS AT 04:06:49 ON WEDNESDAY, APR 04.07.35 JOB05545 $HASP373 DUMPUP01 STARTED - INIT 1- CLASS A - SYS MVST 04.07.35 JOB05545 IEF403I DUMPUP01 - STARTED - TIME=04.07.35 04.07.35 JOB05545 - --TIMINGS (MINS.)- 04.07.35 JOB05545 -JOBNAME STEPNAME PROCSTEPRC EXCPCPU SRB CLOC 04.07.35 JOB05545 -DUMPUP01 STEP2 12230.00 .00.0 04.07.35 JOB05545 IEF404I DUMPUP01 - ENDED - TIME=04.07.35 04.07.35 JOB05545 -DUMPUP01 ENDED. NAME- TOTAL CPU TIME= 04.07.35 JOB05545 $HASP395 DUMPUP01 ENDED 0-- JES2 JOB STATISTICS -- - 06 APR 2011 JOB EXECUTION DATE - 32 CARDS READ - 78 SYSOUT PRINT RECORDS -0 SYSOUT PUNCH RECORDS -6 SYSOUT SPOOL KBYTES - 0.00 MINUTES EXECUTION TIME 1 //DUMPUP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=SYSUID IEFC653I SUBSTITUTION JCL - CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY= 2 //STEP2 EXEC PGM=ADRDSSU,REGION=4M,PARM='TYPRUN=NORUN' 3 //SYSPRINT DD SYSOUT=* 4 //INVOL1DD VOL=SER=DMTRES,UNIT=3390,DISP=SHR 5 //OUTVOL1 DD VOL=SER=RES001,UNIT=3390,DISP=SHR 6 //SYSIN DD * ICH70001I SYSPRG1 LAST ACCESS AT 04:06:49 ON WEDNESDAY, APRIL 6, 2011 IEF236I ALLOC. FOR DUMPUP01 STEP2 IEF237I JES2 ALLOCATED TO SYSPRINT IEF237I 0100 ALLOCATED TO INVOL1 IEF237I 0206 ALLOCATED TO OUTVOL1 IEF237I JES2 ALLOCATED TO SYSIN IEF142I DUMPUP01 STEP2 - STEP WAS EXECUTED - COND CODE 0012 IEF285I SYSPRG1.DUMPUP01.JOB05545.D102.? SYSOUT IEF285I SYS11096.T040735.RA000.DUMPUP01.R0100020 KEPT IEF285I VOL SER NOS= DMTRES. IEF285I SYS11096.T040735.RA000.DUMPUP01.R0100021 KEPT IEF285I VOL SER NOS= RES001. IEF285I SYSPRG1.DUMPUP01.JOB05545.D101.? SYSIN IEF373I STEP/STEP2 /START 2011096.0407 IEF374I STEP/STEP2 /STOP 2011096.0407 CPU0MIN 00.10SEC SRB 0MIN 00.04 IEF375I JOB/DUMPUP01/START 2011096.0407 IEF376I JOB/DUMPUP01/STOP 2011096.0407 CPU0MIN 00.10SEC SRB 0MIN 00.04 1PAGE 0001 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.096 04:07 -ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN MO COPY DATASET(INCLUDE(**) - 0006000 EXCLUDE(SYS1.VTOCIX.** - 0007000 SYS1.VVDS.** - 0008000 SYSUCAT.** - 0009000 OMVS.**- 001 MVSSMP*.** - 0011000 )) - 0012000 LOGINDDNAME(INVOL1) - 0013000 ALLDATA(*) - 0014000 ALLEXCP - 0015000 CANCELERROR - 0016000 BYPASSACS(**) - 0017000 FORCE - 0018000 NULLMGMTCLAS - 0019000 NULLSTORCLAS - 002 OUTDDNAME(OUTVOL1) - 0021000 PERCENTUTILIZED(100) - 0022000 PROCESS(SYS1
Re: ADRDSSU issue
Hello Jags, It is not about coping only IODF cluster file. This problem is in general coping VSAM dataset along with NON VSAM dataset. The last JCL which you suggested, that has worked out with Non VSAM dataset, but in my some of the volume I do have VSAM dataset as well, so I was looking for the parameter, which can also copy VSAM as well. Regards Saurabh Khandelwal On 4/6/2011 6:59 AM, jagadishan perumal wrote: Hi, 1) Instead of copying your IODF cluster. You can even use your existing IODF and Just IPL from the address of the new COD sysres volume, but point LOADPARM at your normal IODF volume. 2) Or else you can define a new Cluster at the target volume and copy the existing IODF cluster from the source using the load module CBDMGHCP. You can google it to find the sample JCL for CBDMGHCP. Regards, Jags On Tue, Apr 5, 2011 at 8:48 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com mailto:saurabh.khandel...@oracle.com wrote: Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* *SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen luckychenluck...@gmail.com mailto:chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWALsaurabh.khandel...@oracle.com mailto:saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu mailto:IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com mailto:john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To:IBM-MAIN@bama.ua.edu mailto:IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com mailto:john.mck...@healthmarkets.com *www.HealthMarkets.com http://www.healthmarkets.com/http://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may
Re: ADRDSSU issue
Saurabh, I pressume you are trying to perform DASD migration, so looking into your Output only the IODF related Datasets(VSAMS) were not copied successfully. Let me know if you accomplish copying the IODF VSAM using some parameters that would meet your Objective. Regards, Jags On Wed, Apr 6, 2011 at 10:16 AM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello Jags, It is not about coping only IODF cluster file. This problem is in general coping VSAM dataset along with NON VSAM dataset. The last JCL which you suggested, that has worked out with Non VSAM dataset, but in my some of the volume I do have VSAM dataset as well, so I was looking for the parameter, which can also copy VSAM as well. Regards Saurabh Khandelwal On 4/6/2011 6:59 AM, jagadishan perumal wrote: Hi, 1) Instead of copying your IODF cluster. You can even use your existing IODF and Just IPL from the address of the new COD sysres volume, but point LOADPARM at your normal IODF volume. 2) Or else you can define a new Cluster at the target volume and copy the existing IODF cluster from the source using the load module CBDMGHCP. You can google it to find the sample JCL for CBDMGHCP. Regards, Jags On Tue, Apr 5, 2011 at 8:48 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* * SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen lucky chenluck...@gmail.com chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWAL saurabh.khandel...@oracle.com saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com http://www.healthmarkets.com/http://www.healthmarkets.com/ http://www.healthmarkets.com/ Confidentiality Notice
Re: ADRDSSU issue
No, I am not using any parameter for coping VSAM dataset. I was asking you to suggest me , if you have idea about any parameter, which can be useful for coping VSAM dataset. Regards Saurabh Khandelwal On 4/6/2011 10:52 AM, jagadishan perumal wrote: Saurabh, I pressume you are trying to perform DASD migration, so looking into your Output only the IODF related Datasets(VSAMS) were not copied successfully. Let me know if you accomplish copying the IODF VSAM using some parameters that would meet your Objective. Regards, Jags On Wed, Apr 6, 2011 at 10:16 AM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello Jags, It is not about coping only IODF cluster file. This problem is in general coping VSAM dataset along with NON VSAM dataset. The last JCL which you suggested, that has worked out with Non VSAM dataset, but in my some of the volume I do have VSAM dataset as well, so I was looking for the parameter, which can also copy VSAM as well. Regards Saurabh Khandelwal On 4/6/2011 6:59 AM, jagadishan perumal wrote: Hi, 1) Instead of copying your IODF cluster. You can even use your existing IODF and Just IPL from the address of the new COD sysres volume, but point LOADPARM at your normal IODF volume. 2) Or else you can define a new Cluster at the target volume and copy the existing IODF cluster from the source using the load module CBDMGHCP. You can google it to find the sample JCL for CBDMGHCP. Regards, Jags On Tue, Apr 5, 2011 at 8:48 PM, SAURABH KHANDELWAL saurabh.khandel...@oracle.com wrote: Hello, Along with PS and PDS i am also coping VSAM dataset available like IODF cluster file etc and getting below error. 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODFD0.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF00.WORK.CLUSTER IN CATALOG LOG.MASTER.MCAT IS NOT PROCESSABLE 0ADR468E (001)-DDFLT(04), VSAM DATA SET SYS1.IODF01.WORK.CLUSTER IN CATALOG CATALOG.MASTER.MCAT IS NOT PROCESSABLE DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZARNT3 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET SYS1.SBLSPNL0 ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZAINST ALLOCATED, ON VOLUME(S): RES001 DR396I (001)-NEWDS(01), DATA SET TCPIP.SEZATCP ALLOCATED, ON VOLUME(S): RES001 DR801I (001)-DDDS (01), DATA SET FILTERING IS COMPLETE. 262 OF 262 DATA SETS WE FOR OTHER REASONS. DR455W (001)-DDDS (01), *THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED* * SYS1.IODFD0.WORK.CLUSTER SYS1.IODF00.WORK.CLUSTER SYS1.IODF01.WORK.CLUSTER* DR454I (001)-DDDS (02), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED ISF.SISFHELP SYS1.SCUNLOCL TCPIP.SEZAXAWL CEE.SCEESAMP SYS1.SISTASN1 SYS1.SBPXMENU AGE 0011 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2011.095 14:07 On 4/5/2011 8:33 PM, jagadishan perumal wrote: Hi, Incase if you are trying to move your HSM control Files(MCDS,OCDS,BCDS). Then probably you might get this error because HSM control files are Normal VSAM files. If this is your case then you have to stop HSM and Invoke DFDSS to move on the VSAM datasets. Regards, Jags On Tue, Apr 5, 2011 at 8:28 PM, chen luckychenluck...@gmail.com chenluck...@gmail.com wrote: In original post, there is no 'delete' parameter specified, but even so, there are still some DataSets had been copied successfully. Do not know why, may these copied ones are not cataloged. 2011/4/5 SAURABH KHANDELWALsaurabh.khandel...@oracle.com saurabh.khandel...@oracle.com Thanks Richard, I tried using STORAGE CLASS parameter( NOSMS). but still got same error. Now I am searching for the parameter you suggested. Regards On 4/5/2011 7:38 PM, Richard Marchant wrote: Saurabh, There is a parameter in ADRDSSU where you can bypass the ACS routines, something like BYPASSACS. Check out the manual. HTH Richard From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] on behalf of McKown, John [john.mck...@healthmarkets.com] Sent: 05 April 2011 03:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU issue My __guess__ is that your STORCLAS ACS routine is assigning a storage class to the new allocations. In my shop, I __must__ specify the parameter: STORAGECLASS(NONSMS) which is tested in the ACS routines to make a dataset non SMS managed. Again, AT MY SHOP, this is a requirement. Why? Because that's how I wrote the ACS routine. The ACS routines are in house written. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone
Re: ADMIN failure using DUMP command in pgm ADRDSSU
Hi Greg, In respect of your query: RUNNING CA'S TOP SECRET 5.0 I'm trying to dump all my disk to tape for a DR test and I believe I need to use the ADMIN keyword. Error when using the ADMIN keyword on the Dump command of pgm ADRDSSU. PAGE 0001 5695-DF175 DFSMSDSS V1R3.0 DATA SET SERVICES 2011.066 DUMP FULL INDD(INVOL) OUTDD(OUTVOL) ADMIN ALLDATA(*) TOL(IOER) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' ADR109I (R/I)-RI01 (01), 2011.066 15:43:57 INITIAL SCAN OF USER CONTROL S ADR707E (R/I)-RI03 (06), NOT AUTHORIZED TO USE ADMINISTRATOR KEYWORD ADR017E (001)-CLTSK(01), 2011.066 15:43:57 TASK NOT SCHEDULED DUE TO ERRO ADR012I (SCH)-DSSU (01), 2011.066 15:43:57 DFSMSDSS PROCESSING COMPLETE. The requirements for ADMIN authority are covered in the DFSMS Storage Administration Reference (for DFSMSdfp, DFSMSdss, DFSMShsm) under the heading DFSMSdss Storage Administrator in the DFDSS section. This lists the applicable RACF profiles for various accesses but should be translatable to Top Secret. Kind Regards - Terry Director KMS-IT Limited 228 Abbeydale Road South Dore Sheffield S17 3LA UK Reg : 3767263 Outgoing e-mails have been scanned, but it is the recipients responsibility to ensure their anti-virus software is up to date. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ADMIN failure using DUMP command in pgm ADRDSSU
RUNNING CA'S TOP SECRET 5.0 I'm trying to dump all my disk to tape for a DR test and I believe I need to use the ADMIN keyword. Error when using the ADMIN keyword on the Dump command of pgm ADRDSSU. PAGE 0001 5695-DF175 DFSMSDSS V1R3.0 DATA SET SERVICES 2011.066 DUMP FULL INDD(INVOL) OUTDD(OUTVOL) ADMIN ALLDATA(*) TOL(IOER) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' ADR109I (R/I)-RI01 (01), 2011.066 15:43:57 INITIAL SCAN OF USER CONTROL S ADR707E (R/I)-RI03 (06), NOT AUTHORIZED TO USE ADMINISTRATOR KEYWORD ADR017E (001)-CLTSK(01), 2011.066 15:43:57 TASK NOT SCHEDULED DUE TO ERRO ADR012I (SCH)-DSSU (01), 2011.066 15:43:57 DFSMSDSS PROCESSING COMPLETE. Below is my Top Secret accesses but I can't figure out what else I need to use the ADMIN keyword. READY TSS LIST(GLC) DATA(ALL,PASSWORD) ACCESSORID = GLC NAME = CASERTA, GREG TYPE = CENTRAL SIZE = 512 BYTES FACILITY = *ALL* CREATED= 01/29/07 LAST MOD = 03/07/11 14:21 PROFILES = SYSTECP SYSPRGP SALARYP SMCTECH ATTRIBUTES = CONSOLE BYPASSING = NODSNCHK,NOVOLCHK,NORESCHK,NOLCFCHK,NOSUBCHK,NOVMDCHK LAST USED = 03/07/11 15:51 CPU(INCO) FAC(BATCH ) COUNT(25965) XA OTRAN = CEMT OWNER(SYSCOMP ACCESS = ALL INSTDATA = TECHNICAL SUPPORT --- SEGMENT CICS OPIDENT= GLC --- ADMINISTRATION AUTHORITIES RESOURCE = *ALL* ACCESS = ALL ACID = *ALL* FACILITIES = *ALL* LIST DATA = *ALL*,PROFILES,PASSWORD,SESSKEY MISC1 = *ALL* MISC2 = *ALL* MISC8 = *ALL* MISC9 = *ALL* PASSWORD = TSS0300I LIST FUNCTION SUCCESSFUL READY END This document has been scanned by Special Metals Corporation for viruses and inappropriate content. It contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Special Metals Corporation, 3200 Riverside Drive, Huntington, WV 25705, USA, www.specialmetals.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADMIN failure using DUMP command in pgm ADRDSSU
Geez.. why bother having security at all.. just put yourself in MODE(WARN) ... you are almost there anyway. But.. I will say that when it comes to the IBM products, if you don't have a resource defined the resource check is returned with a RC(4) aka No Decision ... it is up to the individual product to decide what to do ... sometimes it lets you do whatever you are trying to do.. other times it will fail the request and not give you a lot of help as to the missing resource name. According to the ADR707E (which gives you all the info you need) TSS PER() IBMFAC(ADMINSTRATOR) Of course it is over 8 characters.. so you can probably get by with TSS ADD(dept) IBMFAC(ADMINIST) TSS PER() IBMFAC(ADMINIST) HTH Rob Schramm -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Greg Caserta Sent: Monday, March 07, 2011 3:59 PM To: IBM-MAIN@bama.ua.edu Subject: ADMIN failure using DUMP command in pgm ADRDSSU RUNNING CA'S TOP SECRET 5.0 I'm trying to dump all my disk to tape for a DR test and I believe I need to use the ADMIN keyword. Error when using the ADMIN keyword on the Dump command of pgm ADRDSSU. PAGE 0001 5695-DF175 DFSMSDSS V1R3.0 DATA SET SERVICES 2011.066 DUMP FULL INDD(INVOL) OUTDD(OUTVOL) ADMIN ALLDATA(*) TOL(IOER) ALLEXCP ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' ADR109I (R/I)-RI01 (01), 2011.066 15:43:57 INITIAL SCAN OF USER CONTROL S ADR707E (R/I)-RI03 (06), NOT AUTHORIZED TO USE ADMINISTRATOR KEYWORD ADR017E (001)-CLTSK(01), 2011.066 15:43:57 TASK NOT SCHEDULED DUE TO ERRO ADR012I (SCH)-DSSU (01), 2011.066 15:43:57 DFSMSDSS PROCESSING COMPLETE. Below is my Top Secret accesses but I can't figure out what else I need to use the ADMIN keyword. READY TSS LIST(GLC) DATA(ALL,PASSWORD) ACCESSORID = GLC NAME = CASERTA, GREG TYPE = CENTRAL SIZE = 512 BYTES FACILITY = *ALL* CREATED= 01/29/07 LAST MOD = 03/07/11 14:21 PROFILES = SYSTECP SYSPRGP SALARYP SMCTECH ATTRIBUTES = CONSOLE BYPASSING = NODSNCHK,NOVOLCHK,NORESCHK,NOLCFCHK,NOSUBCHK,NOVMDCHK LAST USED = 03/07/11 15:51 CPU(INCO) FAC(BATCH ) COUNT(25965) XA OTRAN = CEMT OWNER(SYSCOMP ACCESS = ALL INSTDATA = TECHNICAL SUPPORT --- SEGMENT CICS OPIDENT= GLC --- ADMINISTRATION AUTHORITIES RESOURCE = *ALL* ACCESS = ALL ACID = *ALL* FACILITIES = *ALL* LIST DATA = *ALL*,PROFILES,PASSWORD,SESSKEY MISC1 = *ALL* MISC2 = *ALL* MISC8 = *ALL* MISC9 = *ALL* PASSWORD = TSS0300I LIST FUNCTION SUCCESSFUL READY END This document has been scanned by Special Metals Corporation for viruses and inappropriate content. It contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Special Metals Corporation, 3200 Riverside Drive, Huntington, WV 25705, USA, www.specialmetals.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Strange ADRDSSU behavior (ADR485E)
The following scenario: z/OS 1.11 DSS job COPY DS(INC(**) EXC(SYS1.VVDS.**)) - LOGINDDNAME(IND) - CANCELERROR TOLERATE(ENQF) - OUTDD(OTD) ALLDATA(*) ALLEXCP - RECATALOG(CAT.MAST.NEWCAT) - RENAMEU(ZFS.OLDSYS.**,ZFS.NEWSYS.**) The job succesfully copies all ZFS (VSAM LDS) datasets, *except* the following one: ZFS.OLDSYS.SHPUROOT DSS end with RC=8 and te following message. ADR485E (001)-AMOVE(01), CATALOG CAT.MAST.NEWCAT IS NOT IN STEPCAT/JOBCAT/MASTERCAT STRUCTURE. DATA SET ZFS.OLDSYS.SHPUROOT WILL BE PROCESSED. Manual says: he NONSMS cluster named in the message required DFSMSdss to use IDCAMS or VSAM I/O to perform the COPY or RESTORE. This requires that both the source and target cluster (allocated by DFSMSdss) be accessible via the catalog structure. I have no idea why this dataset requires IDCAMS, while other datasets were succesfully processed. Any clue??? BTW: I googled for ADR485E - first hit says about empty cluster - this cluster is NOT empty. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 16.07.2010 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.248.328 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Strange ADRDSSU behavior (ADR485E)
I just went through a similar situation. If I remember what I read, DF/dss actually invokes IDCAMS under the covers to actually perform the action you are trying. IF you dump the zfs dataset, and restore it with a newname, it should work properly. Doug On 16-Nov-10 09:28, R.S. wrote: The following scenario: z/OS 1.11 DSS job COPY DS(INC(**) EXC(SYS1.VVDS.**)) - LOGINDDNAME(IND) - CANCELERROR TOLERATE(ENQF) - OUTDD(OTD) ALLDATA(*) ALLEXCP - RECATALOG(CAT.MAST.NEWCAT) - RENAMEU(ZFS.OLDSYS.**,ZFS.NEWSYS.**) The job succesfully copies all ZFS (VSAM LDS) datasets, *except* the following one: ZFS.OLDSYS.SHPUROOT DSS end with RC=8 and te following message. ADR485E (001)-AMOVE(01), CATALOG CAT.MAST.NEWCAT IS NOT IN STEPCAT/JOBCAT/MASTERCAT STRUCTURE. DATA SET ZFS.OLDSYS.SHPUROOT WILL BE PROCESSED. Manual says: he NONSMS cluster named in the message required DFSMSdss to use IDCAMS or VSAM I/O to perform the COPY or RESTORE. This requires that both the source and target cluster (allocated by DFSMSdss) be accessible via the catalog structure. I have no idea why this dataset requires IDCAMS, while other datasets were succesfully processed. Any clue??? BTW: I googled for ADR485E - first hit says about empty cluster - this cluster is NOT empty. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Strange ADRDSSU behavior (ADR485E)
W dniu 2010-11-16 22:39, Doug Fuerst pisze: I just went through a similar situation. If I remember what I read, DF/dss actually invokes IDCAMS under the covers to actually perform the action you are trying. IF you dump the zfs dataset, and restore it with a newname, it should work properly. The reason is EAV. No, I don't have to do with EAV-capable hardware, but the software has been changed. There are new rules for CA size. The exceptional dataset had CA size which is not used by new system (it was created by downlevel driving system), so during the copy it's be transformed. The rest of datasest (actually I checked only few of them) do have legal CA sizes. So, indeed - dump-restore would help because it would create new dataset with new CA size. BTW: I had very similar issue during upgrade from OS/390 2.10 to z/OS 1.4 - then it was index size changed. Thank everyone who tried to help me Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 16.07.2010 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.248.328 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
Obviously some shops must be radically different. In a full SMS shop, applications programmers of course have no business doing volume-level or volume-specific operations, and to prevent override of RACF access restrictions ADRDSSU ADMIN authority must be tightly restricted to those authorized to perform DASDAdmin functions; but for us to deny applications access to DFDSS for dataset level backup/restore functions on their own application datasets would be counterproductive. We find that SMS configuration and conventions can reasonably be used to handle a few backups, but are completely inadequate for many others where the only kinds of backups that make sense are driven by application-level events, with sets of related datasets that must be handled as a consistent group, and/or with archival retention requirements that don't fit within the rather simplistic SMS management capabilities. As a SysProg it is part of my responsibility to see that we can recover the data center as a whole to a point-in-time in the event of a data center failure. But, I do not have the time, the inclination, or the responsibility to determine what additional backups many different individual application areas may need in order to recover from mini-disasters caused by application program failures, to reprocess old data because of changed end-user requirements, or to meet data archival requirements imposed by management or law specific to that application area. Given that there are of necessity backups that must be designed by and maintained by non-SysProg, applications people who are the ones in the best position to understand their archival requirements, to deny them ADRDSSU, effectively limiting them to sequential file backups and awkward and inefficient file stacking on tape backups, makes little sense. JC Ewing Obviously Scott T. Harder wrote: I can see where IF you have ALL the appropriate security profiles set up properly, then I suppose I see your point. For me, though, I would rather cut off access completely. I would ask Why do they need it? If your SMS constructs and ACS routines, and your backups, are all set up properly, why do they need to be moving data around or backing it up with DSS??? I think my mom *did* say that once or twice, btw. ;-) All the best, Scott T. Harder -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf Of R.S. Sent: Wednesday, May 06, 2009 4:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib] Scott T. Harder pisze: Sorry, guys. In my world, Application Programmers have no business having access to Storage Management utilities like DSS. Period. That needs to remain a centralized function. Why? Because mama said that? Poor justification. In my shop appliccation prgrammers have access to any tool they want, UNLESS it is dangerous, i.e. bypasses regular security checking. That's why DSS is available to everyone, but STGADMIN.ADR.STGADMIN.** is not. -- Radoslaw Skorupka Lodz, Poland ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
Thank you from this applications programmer for the most sensible and reasonable answer and attitude I have yet seen. It would be terrific if every systems programmer and storage administrator and auditor and management were so enlightened. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joel C Ewing Sent: Tuesday, May 12, 2009 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib] Obviously some shops must be radically different. In a full SMS shop, applications programmers of course have no business doing volume-level or volume-specific operations, and to prevent override of RACF access restrictions ADRDSSU ADMIN authority must be tightly restricted to those authorized to perform DASDAdmin functions; but for us to deny applications access to DFDSS for dataset level backup/restore functions on their own application datasets would be counterproductive. We find that SMS configuration and conventions can reasonably be used to handle a few backups, but are completely inadequate for many others where the only kinds of backups that make sense are driven by application-level events, with sets of related datasets that must be handled as a consistent group, and/or with archival retention requirements that don't fit within the rather simplistic SMS management capabilities. As a SysProg it is part of my responsibility to see that we can recover the data center as a whole to a point-in-time in the event of a data center failure. But, I do not have the time, the inclination, or the responsibility to determine what additional backups many different individual application areas may need in order to recover from mini-disasters caused by application program failures, to reprocess old data because of changed end-user requirements, or to meet data archival requirements imposed by management or law specific to that application area. Given that there are of necessity backups that must be designed by and maintained by non-SysProg, applications people who are the ones in the best position to understand their archival requirements, to deny them ADRDSSU, effectively limiting them to sequential file backups and awkward and inefficient file stacking on tape backups, makes little sense. JC Ewing This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
