ADRDSSU Backup of a RLS data set - Failed

[Buckton, T. (Theo)]

Hi There,

VSAM RLS was for the first implemented at our shop. However, we experience 
issues with the ADRDSSU backup of the files, failing with:

ADR952E (001)-DTDSC(01), THE IDAQDMP MACRO FAILED DURING QUIESCE PROCESSING FOR 
CLUSTER DFHSM.P0R0.BCDS WITH RETURN CODE 0008
We are aware that HSM has its own backup mechanism, but we are using the HSM 
CDS files for testing purposes.

One recommendation that I came across is that the DSSTIMEOUT parm be set in the 
IDGSMSxx member in the parmlib, and then to wait until SMSVSAM is refreshed to 
have this activated. Should T SMS=xx not activate this immediately 
(dynamically)?

Another recommendation is to set the BWO to TYPECICS or TYPEIMS. Is this parm 
not applicable to files accessed by CICS only? 

Is there another solution for the ADRDSSU backup failure of RLS accessed files?

Please advise.

Thank you,

Regards 


Nedbank Limited Reg No 1951/09/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]


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

Re: ADRDSSU Compatibility

[Joel C. Ewing]

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 Compatibility

[Ted MacNEIL]

>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

[Joel C. Ewing]

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

[Norbert Friemel]

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

--
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

[Joel C. Ewing]

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

[Norbert Friemel]

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

ADRDSSU Compatibility

[Carlos Bodra - Pessoal]

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 logical dump of VSAM & restore

[McKown, John]

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
> 
> -- 
> 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

Re: ADRDSSU logical dump of VSAM & restore

[John Eells]

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


--
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: ADRDSSU logical dump of VSAM & restore

[Norbert Friemel]

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=dgt2bka0&DT=20100623212334&CASE=

"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

[McKown, John]

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
> > 
> > 
> > 
> 

Re: ADRDSSU logical dump of VSAM & restore

[O'Brien, David W. (NIH/CIT) [C]]

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

[O'Brien, David W. (NIH/CIT) [C]]

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

[McKown, John]

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

[Chase, John]

> -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

[O'Brien, David W. (NIH/CIT) [C]]

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

[R.S.]

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

ADRDSSU logical dump of VSAM & restore

[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?


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: Magical Incantations in ADRDSSU

[Edward Jaffe]

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: Magical Incantations in ADRDSSU

[Justin Eastman]

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

[Edward Jaffe]

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

[Justin Eastman]

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: Change EATTR for Existing Data Sets with IDCAMS ALTER (Was: Magical Incantations in ADRDSSU)

[Edward Jaffe]

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:




[Snip]
To change the EATTR value after a new allocation requires you to run the AMS 
ALTER command.

[Snip]



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

Change EATTR for Existing Data Sets with IDCAMS ALTER (Was: Magical Incantations in ADRDSSU)

[Edward Jaffe]

http://www.redbooks.ibm.com/redbooks/SG247768/wwhelp/wwhimpl/api.htm?href=4-3-3.htm 
contains:



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.



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

Re: Magical Incantations in ADRDSSU

[Mary Anne Matyaz]

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

Re: Magical Incantations in ADRDSSU

[Mary Anne Matyaz]

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

[Mary Anne Matyaz]

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

[Edward Jaffe]

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

[Mary Anne Matyaz]

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

Magical Incantations in ADRDSSU

[Edward Jaffe]

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

RES: Guff! ADRDSSU Restore

[Sérgio Lima Costa]

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, 

Re: Guff! ADRDSSU Restore

[J. Cassidy]

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)
=> //SYSIN    DD  *
=>  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

ADRDSSU Restore

[Sérgio Lima Costa]

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: Restore Error - Adrdssu

[Jim McAlpine]

On Wed, Jun 22, 2011 at 3:30 PM, jagadishan perumal
wrote:

> 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: Restore Error - Adrdssu

[Lizette Koehler]

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

[jagadishan perumal]

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  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  

Re: Restore Error - Adrdssu

[jagadishan perumal]

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  U1

Re: Restore Error - Adrdssu

[Shmuel Metz (Seymour J.)]

In , on 06/22/2011
   at 03:02 PM, jagadishan perumal  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  
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

[Dennis Trojak]

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 wit

Re: Restore Error - Adrdssu

[Larry Macioce]

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

[Elardus Engelbrecht]

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

[Stephen Mednick]

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

[Elardus Engelbrecht]

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

[Jim McAlpine]

On Wed, Jun 22, 2011 at 12:28 PM, Stephen Mednick wrote:

> 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]

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.ht

Re: Restore Error - Adrdssu

[Lizette Koehler]

> 
> 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
>000003 //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

[jagadishan perumal]

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

[Elardus Engelbrecht]

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

[jagadishan perumal]

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 wrote:

> On Wed, Jun 22, 2011 at 11:06 AM, jagadishan perumal
> wrote:
>
> > 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

[Jim McAlpine]

On Wed, Jun 22, 2011 at 11:06 AM, jagadishan perumal
wrote:

> 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

[jagadishan perumal]

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 wrote:

> On Wed, Jun 22, 2011 at 10:32 AM, jagadishan perumal
> wrote:
>
> > 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

[Jim McAlpine]

On Wed, Jun 22, 2011 at 10:32 AM, jagadishan perumal
wrote:

> 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

Restore Error - Adrdssu

[jagadishan perumal]

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: z/OS 1.11 question on DFDSS/ADRDSSU

[Chris Hoelscher]

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

Re: z/OS 1.11 question on DFDSS/ADRDSSU

[Schwarz, Barry A]

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: z/OS 1.11 question on DFDSS/ADRDSSU

[Pommier, Rex R.]

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

[Mike Schwab]

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  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

z/OS 1.11 question on DFDSS/ADRDSSU

[Chris Hoelscher]

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: ADRDSSU issue

[Justin Eastman]

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

[SAURABH KHANDELWAL]

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 A


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

[chen lucky]

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 

> 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

Re: ADRDSSU issue

[Schwarz, Barry A]

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

[Gonzalo Cengotita]

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*
&g

Re: ADRDSSU issue

[Lizette Koehler]

>*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

[SAURABH KHANDELWAL]

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 lucky  
  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  


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/2

Re: ADRDSSU issue

[Michael Wickman]

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  
>  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  
> 
>
> 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

Re: ADRDSSU issue

[Lizette Koehler]

> 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

[Staller, Allan]

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

[Lizette Koehler]

>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

[SAURABH KHANDELWAL]

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 
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

[jagadishan perumal]

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

[SAURABH KHANDELWAL]

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

[Gonzalo Cengotita]

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

[SAURABH KHANDELWAL]

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 lucky  
  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  


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:

Re: ADRDSSU issue

[jagadishan perumal]

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  
>>  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  
>> 
>>
>> 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

Re: ADRDSSU issue

[SAURABH KHANDELWAL]

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 
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 lucky  
<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 KHANDELWAL  
<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 messag

Re: ADRDSSU issue

[SAURABH KHANDELWAL]

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) -  

Re: ADRDSSU issue

[SAURABH KHANDELWAL]

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 ..

//V&FRVOLSER 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

[Ravi Gaur]

aah,forgot remove by condition so job can be ..

//V&FRVOLSER 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

[Ravi Gaur]

use this and let me know what you get..

//V&FRVOLSER 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

[chen lucky]

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 

> add PROCESS(SYS1), then have a try.
>
>
> 2011/4/5 SAURABH KHANDELWAL 
>
>> 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
>>>  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
>>>>
>>>>  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
>>>>
>>>>>

Re: ADRDSSU issue

[chen lucky]

add PROCESS(SYS1), then have a try.

2011/4/5 SAURABH KHANDELWAL 

> 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  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
>>>
>>>  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/>
>>>>>
>>&g

Re: ADRDSSU issue

[jagadishan perumal]

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  
>  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  
> 
>
> 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 subsidi

Re: ADRDSSU issue

[SAURABH KHANDELWAL]

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  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


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(*) 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 ALLO

Re: ADRDSSU issue

[jagadishan perumal]

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  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 
>
> > 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(*) 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
&

Re: ADRDSSU issue

[chen lucky]

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 

> 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
>>

Re: ADRDSSU issue

[jagadishan perumal]

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.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] 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(SYS

Re: ADRDSSU issue

[SAURABH KHANDELWAL]

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.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):
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 iss

Re: ADRDSSU issue

[SAURABH KHANDELWAL]

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/arc

Re: ADRDSSU issue

[jagadishan perumal]

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.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):
> &

Re: ADRDSSU issue

[Richard Marchant]

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

[McKown, John]

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

ADRDSSU issue

[SAURABH KHANDELWAL]

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: ADMIN failure using DUMP command in pgm ADRDSSU

[Terry Sambrooks]

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

Re: ADMIN failure using DUMP command in pgm ADRDSSU

[Rob Schramm]

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

ADMIN failure using DUMP command in pgm ADRDSSU

[Greg Caserta]

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

Strange ADRDSSU behavior (ADR485E)

[R.S.]

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)

[R.S.]

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: Strange ADRDSSU behavior (ADR485E)

[Doug Fuerst]

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